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ABSTRACT 


The  Adaptive  Architectures  for  Command  and  Control  (A2C2)  project  is  a 
four-year  effort  sponsored  by  the  Office  of  Naval  Research  to  explore  adaptation  in 
command  and  control  structures.  The  project’s  first  experiment  involves  studying 
interaction  between  task  structure  and  organization  structure.  Although  the  organization 
structure  dimension  of  interest  was  clear,  not  enough  was  known  of  the  dimensions  of 
task  structure  to  determine  the  dimension  of  interest  without  further  study.  This  thesis 
describes  a  process  for  developing  military  operational  scenarios  within  a  task  structure 
context.  First,  the  author  conducts  a  literature  review,  defines  the  dimensions  of  task 
structure  applicable  to  this  project,  develops  a  grading  scale  for  each  dimension,  gives 
examples  of  the  dimensions  and  grades  each  example,  and  describes  how  changes  in  one 
dimension  might  affect  other  dimensions.  Then  a  method  for  developing  scenarios  in 
accordance  with  a  predetermined  structure  and  visualizing  tasks  is  described,  including  a 
task  structure  diagram  and  a  description  of  a  task  design  process  using  the  diagram  and 
the  dimensions  previously  delineated.  The  author  then  applies  the  task  design  process  by 
developing  two  scenarios  for  the  first  A2C2  experiment  that  differ  across  one  dimension 
of  task  structure,  coordination  requirements.  Finally,  a  description  of  the  experiment  is 
given,  including  discussion  of  operationalization  of  the  scenarios  and  organization 
structures,  and  lessons  learned  from  the  experiment  with  regard  to  scenario  design. 
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EXECUTIVE  SUMMARY 


The  Adaptive  Architectures  for  Command  and  Control  (A2C2)  project  is  a 
four-year  effort,  sponsored  by  the  Office  of  Naval  Research  and  conducted  by  researchers 
at  the  Naval  Postgraduate  School  (NPS),  Alphatech,  Inc.,  the  University  of  Connecticut, 
and  several  other  institutions.  The  goal  of  the  study  is  to  explore  how,  why,  and  when 
organizations  adapt  or  should  adapt  their  structures  and  what  skills,  training,  and 
technology  are  required  to  support  that  adaptation.  The  project  itself  will  consist  of  field 
research  and  a  series  of  experiments. 

The  first  experiment  was  conducted  at  NPS  in  March  1996.  The  purpose  of  this 
initial  experiment  is  to  serve  as  a  “baseline”  for  the  experimental  phase  of  the  A2C2 
project,  and  to  study  interaction  between  task  structure  and  organization  structure,  in  a 
2x2  factorial  experimental  design.  The  organizational  structure  dimension  of  interest  was 
clear  from  the  overarching  purpose  of  the  A2C2  project  and  current  emphasis  in  the 
Department  of  Defense  and  industry  on  “flattening”  organizational  structures:  levels  of 
hierarchy  —  does  a  flattened  hierarchy  perform  tasks  better  under  certain  circumstances 
than  a  hierarchy  with  more  levels?  However,  the  task  structure  dimension  of  interest  was 
less  clear.  Although  there  are  several  discussions  in  the  literature  of  single  dimensions  of 
task  structure,  nowhere  is  there  a  comprehensive  breakdown  of  the  dimensions  of  task 
structure,  including  some  way  of  quantifying  or  determining  the  levels  of  each  of  those 
dimensions  so  they  can  be  held  constant  or  varied  in  a  situation  where  task  structure  is  an 
independent  variable.  And,  once  these  dimensions  are  defined  and  the  dimension  to  be 
varied  has  been  decided  upon,  how  can  a  task  be  visually  represented  for  ease  of 
understanding  and  manipulation,  and  a  military  operational  scenario  be  designed  to  fit 
into  this  task  structure?  This  task  design  and  scenario  development  process  is  the  focus 
of  this  thesis. 

The  author  begins  by  conducting  a  literature  review,  and  defines  the  dimensions  of 
task  structure  applicable  to  this  project  based  on  the  literature  and  his  own  experience. 
These  dimensions  are  uncertainty,  time  pressure,  complexity,  coordination  requirements. 
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magnitude,  resources  required,  information  required,  task  formalization,  and  dynamicity. 
Then,  a  grading  scale  for  each  dimension  is  developed,  examples  of  the  dimensions  are 
given  and  graded  based  on  the  previously  developed  scale,  and  the  author  describes  how 
changes  in  one  dimension  might  affect  other  dimensions. 

Once  the  dimensions  of  task  structure  are  defined  and  a  grading  scale  developed, 
the  author  describes  a  task  structure  diagram,  whose  purpose  is  to  visually  represent  the 
flow  of  activities  within  a  task,  possible  paths,  simultaneity  constraints,  competition  over 
resources,  prerequisites  for  activities,  resources  and  information  required  for  the 
performance  of  activities,  decomposability  of  activities,  and  dynamicity,  or  the  degree  to 
which  activities  change  over  time,  to  experimental  designers.  Many  of  the  dimensions  of 
task  structure  previously  described  are  represented  directly  in  this  diagram;  others  can  be 
inferred  from  it.  This  visual  method  allows  experimenters  to  more  easily  determine  if  a 
task  accomplishes  the  objectives  that  have  been  set,  and  provides  a  straightforward,  visual 
method  for  comparing  it  with  other  tasks  and  for  describing  a  task  to  those  outside  the 
task  design  process.  After  the  diagram  has  been  developed,  the  author  describes  how  the 
dimensions  of  task  structure  defined  previously  relate  to  the  visual  method.  Then,  the 
author  describes  a  straightforward  process  for  developing  military  operational  scenarios 
when  task  structure  is  to  be  an  independent  variable.  The  steps  in  the  process  are  to 
determine  the  task  structure  dimension  of  interest,  determine  desired  task  structure  and 
levels  of  dimensions,  develop  the  scenario,  and  grade  the  scenarios  by  dimensions. 

The  author  then  applies  the  task  design  process  described  above  to  the  A2C2  initial 
experiment.  The  dimension  of  interest  was  determined  by  the  definitions  of  dimensions  of 
task  structure  given  previously  and  initial  A2C2  field  research,  where  the  question  was 
repeatedly  asked:  when  two  units  in  the  same  ftmctional  area  must  compete  over  assets 
owned  by  one  of  them,  does  an  intermediate  level  of  hierarchy  overseeing  that  functional 
area  help,  or  is  a  flattened  hierarchy  better?  And  which  organizational  structure  is  better 
if  the  units  are  competing  over  assets  owned  outside  their  functional  area?  The 
dimension  of  interest,  then,  is  coordination  requirements,  at  two  levels:  high  internal 
competition  over  shared  resources  and  high  external  competition  over  shared  resources. 
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The  author  begins  with  the  scenario  used  for  A2C2  field  research  and  develops  two 
scenarios  at  the  joint  task  force  (JTF)  level  that  differ  across  the  dimension  of  interest, 
and  grades  the  scenarios  based  on  the  dimensions  of  task  structure  developed  previously. 

Finally,  the  author  gives  a  description  of  the  experiment,  including  setup, 
discussion  of  operationalization  of  the  scenarios  and  organization  structures,  training 
conducted  with  the  subjects,  conduct  of  the  experiment  itself,  and  lessons  learned  from 
the  experiment  with  regard  to  scenario  design,  in  terms  of  the  usefulness  of  the  scenario 
design  process  described  in  this  thesis  and  issues  that  must  be  taken  into  account  in  order 
to  effectively  design  and  implement  a  scenario  that  contains  independent  variables. 
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I.  INTRODUCTION 


A.  BACKGROUND 

In  the  effort  to  capitalize  on  the  ongoing  revolution  in  military  affairs,  a  current 
area  of  focus  within  the  Department  of  Defense  is  organization  of  the  force.  New,  more 
highly  evolved  organizational  concepts  are  considered  one  of  the  “enablers  of  the 
revolution  in  military  affairs”  (Joint  Warfighting  Center,  1995,  p.  13).  The  Joint  Staffs 
C4I  for  the  Warrior  (C4IFTW)  concept,  Copernicus,  Sea  Dragon,  and  other  service 
initiatives  that  reside  within  the  overarching  C4IFTW  concept  call  for  flattened  command 
structures.  These  flattened  command  structures  would  make  more  efficient  use  of 
enhanced  sensor-to-shooter  communications  capabilities  and  the  dominant  battlespace 
knowledge  that,  it  is  hoped,  U.S.  forces  are  on  the  road  to  achieving  as  a  result  of  the 
tremendous  pace  of  technological  advance  and  our  leveraging  of  that  technology.  Further, 
it  is  posited  that  the  most  responsive  and  capable  organizations  will  adapt  their  structures 
and  processes  from  traditional,  rigid  hierarchical  organizational  structures  into  more 
flexible,  network-like  architectures  in  order  to  take  advantage  of  the  opportunities 
presented  by  the  information  age  (Joint  Warfighting  Center,  1995,  p.  18). 

B.  THE  A2C2  PROJECT 

It  was  within  this  context  that,  in  the  summer  of  1995,  the  Office  of  Naval 
Research  (ONR)  commissioned  a  four-year  research  project  called  Adaptive 
Architectures  for  Command  and  Control  (A2C2).  The  A2C2  project  is  a  joint  effort  of 
researchers  at  the  Naval  Postgraduate  School  (NPS),  Alphatech,  Inc.,  the  University  of 
Connecticut,  and  several  other  academic  institutions.  The  project’s  goal  is  to  advance  the 
state  of  knowledge  regarding  decision  making  in  organizational  settings,  to  include  an 
understanding  of  how,  why,  and  when  organizations  adapt  or  should  adapt  and  what 
skills,  training,  and  technology  are  required  to  support  that  adaptation 
(Alphatech/UCONN/NPS,  1995,  p.  2).  The  researchers  will  make  use  of  theory,  practical 
experiments,  and  field  observation  in  order  to  gain  this  understanding.  The  A2C2  project 
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will  move  through  several  different  phases,  which  began  in  late  1995  with  visits  to 
military  organizations,  participation  in  demonstrations  and  wargames,  and  a  round  of 
structured  interviews  with  experienced  commanders  from  all  branches  of  the  U.S.  Armed 
Forces.  The  purpose  of  this  field  research  was  to  identify  drivers  of  adaptation  in  joint 
operations,  from  the  perspective  of  those  experienced  in  joint  operations,  and  raise  the 
specific  issues  that  can  and  should  be  dealt  with  in  the  project’s  later  experiments. 

After  the  interviews,  the  A2C2  researchers  have  begun  to  conduct  a  series  of 
experiments  of  gradually  increasing  complexity  and  fidelity.  Each  experiment  will  build 
upon  the  insights  gained  from  modeling,  the  field  research,  and  previous  experiments, 
and  will  be  conducted  using  wargame/simulators  of  complexity  and  fidelity 
commensurate  with  the  experiment  being  conducted.  This  thesis  involves  the  first  of 
those  experiments,  which  was  conducted  using  the  Distributed  Dynamic  Decisionmaking 
III  (DDD-III)  simulator,  a  relatively  low-fidelity,  high-abstraction  tool,  with  officer 
students  from  NFS  representing  each  branch  of  the  service  as  subjects. 

C.  THE  FIRST  A2C2  EXPERIMENT 

The  first  experiment  in  the  A2C2  project  was  conducted  at  NFS  in  March  1996. 
The  purpose  of  this  initial  experiment  was  to  serve  as  a  “baseline”  for  the  experimental 
phase  of  the  A2C2  project.  Objectives  included:  adapting  the  existing  game  simulator 
(DDD  III)  to  the  broader  operational  domain;  examining  organizational  structure  as  an 
independent  variable,  and  testing  interaction  between  organizational  structure  and  task 
structure;  identifying  current  research  issue(s)  that  are  common  to  the  operational  and 
theoretical  (from  literature)  domains,  that  can  be  examined  within  the  context  of  the 
scenario  used  in  the  interviews;  developing  the  scenario  and  tasks  down  to  a  level 
amenable  to  modeling  analytically  and  in  simulation;  providing  insight  into 
wargame/simulator  requirements  for  future  experiments;  and  examining  measures  that 
may  be  useful  for  research  into  adaptable  C2  architectures. 

The  first  experiment  was  conducted  at  the  intersection  of  a  number  of  constraints. 
These  included  the  field  research  that  had  been  conducted,  to  include  the  joint  officer 
interviews  and  field  visits  to  exercises  and  warfighting  commands;  the  pool  of 
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experiment  subjects  at  NPS;  the  requirement  that  any  scenario  developed  be  joint  in  its 
nature;  the  hardware  available  to  conduct  the  experiment  at  NPS;  the  factors  of  interest  to 
the  A2C2  project;  the  requirement  that  the  experiment  be  conducive  to  modeling  and 
simulation;  and  the  capabilities  and  limitations  of  DDD  III. 

Testing  the  organizational  structure/task  structure  interaction  was  the  driver  of  the 
experimental  design.  When  testing  this  interaction,  in  order  to  isolate  effects,  it  was 
desired  that  task  structure  and  organizational  structure  be  varied  in  only  one  dimension 
each,  holding  all  others  constant.  This  resulted  in  a  2^  factorial  design,  with  each  factor 
held  at  two  levels.  The  A2C2  team  decided  to  use  four  six-person  teams,  composed  of 
military  officers  from  all  four  services  with  normally  one  or  two  operational  tours  behind 
them,  conducting  four  trials  per  team  in  a  balanced,  full-factorial  design  with  four  data 
points  in  each  task/organization  structure  combination. 

The  difficult  question,  then,  is  which  dimensions  of  organizational  structure  and 
task  structure  should  be  varied?  And,  once  that  is  decided,  at  what  two  levels  should  the 
dimensions  be  held?  The  overarching  purpose  of  the  A2C2  project  and  the  current  issues 
being  addressed  in  Copernicus  and  C4IFTW  suggested  clearly  that,  in  the  case  of 
organizational  structure,  the  dimension  of  interest  should  be  levels  of  hierarc^:  is 
performance  of  an  organization  enhanced  if  one  or  more  levels  of  hierarchy  is  removed 
(the  “flattened”  structure  envisioned  as  superior  in  the  technology-enhanced  near  future), 
particularly  in  an  environment  where  there  exists  a  common  operational  picture  (COP) 
among  all  members  of  an  organizational  structure?  The  A2C2  team  further  decided  that 
the  two  levels  to  be  tested  should  be  a  two-tiered  hierarchy  and  a  three-tiered  hierarchy 
(Figure  1).  Task  structure,  though,  was  more  difficult.  While  the  literature  on  the  subject 
of  organizational  structure  is  rich,  plentiful,  and  well-developed,  that  regarding  task 
structure  is  not.  Although  there  are  several  discussions  in  the  literature  of  single 
dimensions  of  task  structure,  such  as  complexity,  uncertainty,  or  coordination 
requirements,  nowhere  is  there  a  comprehensive  breakdown  of  the  dimensions  of  task 
structure,  including  some  way  of  quantifying  or  determining  the  levels  of  each  of  those 
dimensions  so  they  can  be  held  constant  or  varied  in  a  situation  where  task  structure  is  an 
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independent  variable.  And,  once  the  dimensions  of  task  structure  are  defined,  the 
dimension  to  be  varied  has  been  decided  upon,  and  the  structural  form  which  the  task  will 
take  has  been  determined,  how  can  a  military  operational  scenario  be  built  to  fit  into  this 
task  structure?  This  task  design  and  scenario  development  process  is  the  focus  of  the 
thesis. 


Organization  Structures 

CJTF 

MCC 

ARG  CVBG 

CJTF 

ARG  CVBG 

Figure  1.  Two  Organization  Structures  Used  for  First  Experiment 

D.  FOCUS  OF  THESIS 

The  purpose  of  this  thesis  is  to  develop  a  process  for  developing  military 
operational  scenarios  within  a  task  structure  context.  As  a  starting  point,  I  will  perform  a 
comprehensive  literature  review,  define  the  dimensions  of  task  structure,  quantify  those 
dimensions,  and  give  examples  of  each  dimension  and  quantifications  of  the  examples 
(Chapter  II).  I  will  then  develop  a  diagram  to  be  used  for  developing  scenarios  in 
accordance  with  a  predetermined  structure,  and  correlate  the  dimensions  of  task  structure 
that  I  define  in  Chapter  II  with  the  elements  of  the  task  structure  diagram,  and  briefly 
outline  a  task  design  process  based  on  the  dimensions  from  Chapter  II  and  the  task 
structure  diagram  (Chapter  III).  I  will  subsequently  develop  two  joint  tactical  scenarios 
written  for  the  DDD  simulator  that  differ  across  the  dimension  of  task  structure  that  the 
A2C2  experimental  team  decides  is  the  most  important  one,  and  in  conjunction  with  the 
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predetermined  structure  that  the  A2C2  team  decides  that  it  wants  to  use,  utilizing  the  task 
design  process  from  Chapter  III.  The  results,  analysis,  and  conclusions  of  the  first  A2C2 
experiment  are  outside  the  scope  of  this  thesis.  However,  I  will  describe  the  conduct  of 
the  experiment  and  operationalization  of  the  scenarios  and  organization  structures 
(Chapter  IV).  Finally,  I  will  detail  lessons  learned  from  the  experiment  and  application  of 
the  task  design  process  as  they  pertain  to  scenario  development  and  task  design,  and  I  will 
summarize  the  thesis  (Chapter  V). 
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11.  DEFINING  DIMENSIONS  OF  TASK  STRUCTURE 


A.  INTRODUCTION 

It  is  clear  that,  in  order  to  successfully  determine  which  types  of  organizations 
function  best  with  different  sorts  of  tasks,  an  organized  and  disciplined  method  with 
which  to  cause  tasks  to  be  different  must  exist.  In  order  to  cause  tasks  to  be  different,  we 
must  be  able  to  differentiate  between  tasks.  And,  before  we  can  differentiate  between 
tasks,  a  task  must  be  characterized.  One  way  to  characterize  tasks  is  to  decompose  each 
task  by  the  level  of  its  various  dimensions.  What,  though,  are  those  dimensions  of  task 
structure?  As  mentioned  in  the  previous  chapter,  there  is  little  in  the  literature  of 
organization  theory  and  behavioral  decision  theory  with  regard  to  dimensions  of  task 
structure.  Discussions  of  one  or  several  dimensions  of  task  structure  are  common  (Wood, 
1986,  Campbell,  1988,  Malone  and  Crowston,  1994,  Ben  Zur  and  Breznitz,  1981,  Davis 
et  al.,  1991,  Evaristo  et  al.,  1995),  but  a  comprehensive  enumeration  of  these  dimensions 
is  lacking. 

The  purpose  of  this  chapter  is,  first,  to  review  the  literature  on  the  subject  of  task 
structure.  Next,  I  will  enumerate  and  define  dimensions  of  task  structure,  based  partly  on 
the  literature  and  partly  on  my  professional  experience,  and  develop  a  grading  scale  for 
each  dimension.  I  will  then  give  examples  of  tasks  that  clearly  exhibit  the  dimension  of 
interest,  and  grade  each  example  given  using  the  seale  developed  earlier.  Finally,  I  will 
discuss  the  interaction  between  dimensions  or  the  degree  to  which  changing  one 
dimension  affects  other  dimensions. 

B.  LITERATURE  REVIEW 

The  literature  on  dimensions  of  task  structure  is  mainly  composed  of  articles  and 
papers  from  technical  journals.  The  works  described  below  are  the  most  significant  to 
date  from  the  perspective  of  enumerating  dimensions  of  task  structure.  Six  articles  are 
discussed:  Wood  (1986)  and  Campbell  (1988)  deal  with  complexity,  Malone  and 
Crowston  (1994)  consider  eoordination  requirements,  Ben  Zur  and  Breznitz  (1981)  deal 
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with  time  pressure,  Evaristo  et  al.  (1995)  describe  time  pressure  and  uncertainty, 
and  Davis  et  al.  (1991)  discuss  task  activities,  time  frame,  task  formalization,  task 
ambiguity,  task  complexity  (using  Wood’s  (1986)  definition),  and  task  significance. 

1.  Wood 

Robert  E.  Wood,  in  his  article,  “Task  Complexity:  Definition  of  the  Construct” 
(1986),  first  states  that  tasks  contain  three  components:  (1)  the  product,  or  what  is 
produced  by  completing  the  task;  (2)  acts,  or  things  that  must  be  done  in  order  to 
complete  the  task;  and  (3)  information  cues,  or  information  that  provides  the  stimulus  for 
performance  of  a  task,  or  is  required  for  the  task  to  be  completed.  He  then  defines  task 
complexity  in  terms  of  these  three  task  components,  and  decomposes  task  complexity 
into  three  different  components:  component  complexity,  coordinative  complexity,  and 
dynamic  complexity,  and  discusses  methods  for  quantifying  each  of  the  components. 

a.  Component  Complexity 

Component  complexity  is  a  direct  function  of  the  number  of  distinct  acts 
that  must  be  completed  in  the  performance  of  the  task  and  the  number  of  distinct 
information  cues  that  must  be  processed  in  order  to  perform  the  acts.  Wood  gives  the  sum 
TC„  the  measure  of  component  complexity,  as  the  sum  of  information  cues  for  all  acts  of 
all  subtasks  within  the  task. 

b.  Coordinative  Complexity 

Coordinative  complexity,  as  defined  by  Wood,  refers  to  the  relationships 
between  task  inputs  and  task  products.  It  describes  the  form  and  strength  of  the 
relationships  between  information  cues,  acts,  and  products,  as  well  as  the  sequencing  of 
inputs.  Wood  gives  a  number  of  different  indices  with  which  to  attempt  to  measure 
coordinative  complexity,  most  of  which  are  a  bit  obscure  and  difficult  to  obtain,  and  I 
will  not  elaborate  on  them  because  of  the  space  that  would  require.  The  most 
straightforward  is  the  sum  of  all  precedence  relations  between  each  act  and  all  other  acts 
in  the  task,  which  he  denotes  TCj. 
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c.  Dynamic  Complexity 

Wood  defines  dynamic  complexity  as  changes  in  the  task  environment 
which  affect  the  relationships  between  task  inputs  and  products.  He  measures  this  by 
summing  the  changes  in  TC,  and  TCj  over  discrete  time  periods,  reduced  by  the  change 
multiplied  by  a  predictability  coefficient  for  each  time  period,  to  arrive  at  a  dynamic 
complexity  figure  denoted  TC3. 

d.  Total  Complexity 

To  arrive  at  a  figure  for  total  complexity.  Wood  obtains  a  weighted  sum  of 
the  TC,,  TCj,  and  TC3  totals.  The  specific  weights,  represented  by  coefficients,  assigned 
to  each  sum  would  be  situationally  dependent,  constrained  by  the  requirement  that  TC,  be 
more  heavily  weighted  than  TC2,  and  TC2  more  heavily  weighted  than  TC3. 

2.  Campbell 

Donald  J.  Campbell,  in  his  article  “Task  Complexity:  A  Review  and  Analysis” 
(1988),  took  a  different  approach  to  defining  complexity.  He  posited  that  task  complexity 
is  closely  related  to  information,  and  that  any  task  attributes  that  increase  the  load, 
diversity,  or  rate  of  change  of  information  should  be  considered  contributors  to  task 
complexity.  He  found  four  task  characteristics  that  meet  that  criterion:  the  degree  to 
which  a  task  contains  multiple  paths,  multiple  outcomes,  conflicting  interdependence 
among  paths,  and  uncertain  or  probabilistic  linkages. 

a.  Multiple  Paths 

Increasing  the  number  of  possible  ways  to  complete  a  given  task  increases 
the  complexity  of  the  task.  This  is  particularly  true  if  the  paths  vary  in  their  “goodness,” 
that  is,  some  paths  more  efficiently  or  effectively  complete  the  task  than  others. 
Complexity  is  reduced  if  all  paths  presented  are  of  equal  goodness. 
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b.  Multiple  Outcomes 

Outcomes  are  the  different  results  the  performer  of  the  task  wants  to 
achieve  when  the  task  is  completed.  The  greater  the  number  of  different  outcomes,  the 
more  complex  the  task. 

c.  Conflicting  Interdependence  Among  Paths 

Campbell  defines  this  as  negative  relationships  among  desired  outcomes. 
If  achieving  one  outcome  conflicts  with  achieving  another  outcome,  task  complexity 
increases. 


d.  Uncertain  or  Probabilistic  Linkages 

Campbell  defines  linkages  as  the  connection  between  potential  path 
activities  and  desired  task  outcomes.  If  there  is  difficulty  determining  these  linkages,  or 
the  linkages  have  a  probability  of  less  than  one,  information  processing  requirements  are 
increased  significantly,  and  task  complexity  increases. 

3.  Malone  and  Crowston 

Thomas  W.  Malone  and  Kevin  Crowston,  in  their  paper  “The  Interdisciplinary 
Study  of  Coordination”  (1994)  define  coordination  as  managing  dependencies  between 
activities.  They  defined  four  different  types  of  dependencies  that  could  need  to  be 
managed:  shared  resources,  producer/consumer  relationships,  simultaneity  constraints, 
and  task/subtask  relationships. 

a.  Managing  Shared  Resources 

Whenever  more  than  one  actor  or  activity  requires  a  limited  resource, 
coordination  is  required  to  ensure  that  the  resource  is  properly  allocated  among  the  actors 
or  activities. 


b.  Managing  Producer/Consumer  Relationships 

A  producer/consumer  relationship  is  one  in  which  one  actor  or  activity 
produces  something  that  is  used  by  another  actor  or  activity. 
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c.  Managing  Simultaneity  Constraints 

Simultaneity  constraints  occur  where  more  than  one  activity  must  be 
performed  at  the  same  time  as  another,  or  when  one  activity  must  be  performed  at  a 
specific  time  in  relation  to  the  performance  of  another  activity. 

d.  Managing  Task/Subtask  Relationships 

Task/subtask  relationships  occur  when  a  task  must  be  broken  up  into 
multiple  subtasks,  and  the  subtasks  divided  up  among  multiple  actors  or  different  time 
periods  for  completion. 

4.  Davis,  Collins,  Eierman,  and  Nance 

Gordon  Davis,  Rosann  Webb  Collins,  Michael  Eierman,  and  William  Nance,  in 
their  working  paper  “Conceptual  Model  for  Research  on  Knowledge  Work”  (1991) 
discuss  characteristics  of  task  environment  that  apply  to  knowledge  tasks  rather  than 
manual  tasks.  They  came  the  closest,  of  any  work  with  which  1  am  familiar,  of  attempting 
to  somewhat  comprehensively  enumerate  dimensions  of  task  structure,  although  I  do  not 
believe  that  their  enumeration  is  complete,  or  that  they  even,  in  some  cases,  considered 
the  right  dimensions.  However,  some  of  the  characteristics  they  describe  are  quite  useful. 
They  discuss  six  characteristics:  task  activities,  time  frame,  task  formalization,  task 
ambiguity,  task  complexity,  and  task  significance,  of  which  formalization,  ambiguity,  and 
complexity  are  the  most  suitable  for  the  purposes  of  this  thesis. 

a.  Task  Activities 

Davis  et  al.  define  task  activities  as  the  operations  that  must  be 
implemented  to  complete  a  task,  with  each  activity  being  associated  with  one  or  more 
problem  spaces. 

b.  Time  Frame 

The  amount  of  time  it  will  take  to  complete  a  task. 
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c. 


Task  Formalization 


The  authors  consider  task  formalization  to  be  the  level  of  specification  and 
structure  that  is  imposed  on  the  performance  of  the  task,  or  task  inputs  or  outputs.  A  task 
with  high  formalization  would  be  described  in  a  very  structured  way;  there  are  certain 
well-defined  activities  that  must  be  performed  in  a  explicit  order  to  complete  the  task.  In 
a  task  with  low  formalization,  though,  the  activities  required  to  complete  the  task,  and 
even  the  goals  of  the  task,  would  be  poorly  defined  and  open  to  interpretation. 

d.  Task  Ambiguity 

Task  ambiguity  is  defined  as  the  clarity  of  imderstanding  of  the  activities 
that  are  required  to  complete  a  task,  or  of  the  inputs  or  outputs  of  a  task. 

e.  Task  Complexity 

The  authors  use  Wood’s  (1986)  definition  of  complexity. 

f.  Task  Significance 

Task  significance  is  defined  as  the  value  of  the  task  output  to  the 
organization  performing  the  task,  and  the  interdependency  between  task  outputs  and  other 
operations  of  the  organization. 

5.  Evaristo,  Adams,  and  Curley 

Roberto  Evaristo,  Carl  Adams,  and  Shawn  Curley,  in  their  article  “Information 
Load  Revisited:  A  Theoretical  Model”  (1995)  describe  three  task  characteristics:  time 
pressure,  task  formalization,  and  task  complexity.  The  authors  define  time  pressure  as  the 
time  available  to  perform  the  task,  and  reiterate  Davis  et  al.’s  (1991)  definition  of  task 
formalization  and  Wood’s  (1986)  definition  of  task  complexity.  Their  most  interesting 
contribution  is  their  description  of  uncertainty,  although  they  do  not  consider  it  a  task 
characteristic,  but  an  information  characteristic.  They  define  uncertainty  as  knowledge 
inadequacy,  resulting  in  an  actor’s  inability  to  predict  something  accurately.  They  fiuther 
cite  the  sources  of  uncertainty  as  unavailability  or  incompleteness  of  information,  low 
information  reliability,  and  information  novelty. 
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6. 


Ben  Zur  and  Breznitz 


Hasida  Ben  Zur  and  Shlomo  J.  Breznitz,  in  their  article  “The  Effect  of  Time 
Pressure  on  Risky  Choice  Behavior”  (1981)  define  time  pressure  as  the  amount  of 
information  that  must  be  considered  and  processed  during  one  time  unit,  or  as  the  time 
allotted  for  processing  a  fixed  amount  of  information.  Their  definition  refers  to  time 
pressure  in  the  information  domain,  but  it  could  be  generalized  to  include  the  task  domain 
as  well. 

C.  ENUMERATION  OF  DIMENSIONS  OF  TASK  STRUCTURE 

The  dimensions  of  task  structure  are  the  concepts  by  which  a  task  can  be 
described.  Below  is  an  attempt  to  comprehensively  define  the  dimensions  of  task 
structure  that  are  of  interest  in  experimentation,  particularly  within  the  A2C2  context. 
Nine  dimensions  are  detailed:  uncertainty,  time  pressure,  complexity,  coordination 
requirements,  magnitude,  resources  required,  information  required,  task  formalization, 
and  dynamicity.  These  dimensions  would  ideally  be  orthogonal,  but  if  complete 
orthogonality  is  possible,  it  would  certainly  have  come  at  a  price  in  comprehensiveness 
that  I  was  not  willing  to  pay.  Thus,  there  is  some  interaction  between  dimensions  (which 
will  be  discussed  in  the  section  following),  although  I  believe  it  is  minimized.  For  each 
dimension  of  task  structure,  I  give  a  definition  and  an  example  in  a  military  operational 
context,  and  then  describe  how  any  given  task  could  be  graded  in  that  dimension  by 
establishing  levels  at  which  the  dimension  could  be  measured.  I  then  grade  the  example 
given  with  the  definition. 

1.  Uncertainty 

a.  Definition 

Uncertainty  is  defined  as  the  degree  to  which  information  about  states, 
inputs,  outcomes,  or  environments  of  tasks  is  unknown  (Evaristo,  et  al.,  p.  200). 
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b. 


Levels 


This  dimension  is  difficult  to  quantify,  and  grading  must  be  done  on  a 
subjective  basis.  There  are  a  number  of  ways  to  subjectively  grade  dimensions,  which 
will  be  used  throughout  this  chapter.  First,  anchored  scales  can  be  used.  Anchored  scales 
are  scales  of  measurement  (from  0  to  100,  for  example)  in  which  illustrations  are  given  of 
a  task  that  would  be  graded  (“anchored”)  at  various  points  on  the  scale,  typically  the  high 
and  the  low  ends.  For  example,  if  “uncertainty”  was  graded  using  an  anchored  scale,  an 
event  of  which  absolutely  no  information  about  states,  inputs,  outcomes,  or  environments 
was  known  would  be  considered  a  “0,”  and  an  event  about  which  all  information  about 
states,  inputs,  outcomes,  or  environments  was  known  would  be  considered  a  “100.”  The 
benefit  of  an  anchored  scale  is  that  it  allows  for  a  moderate  amount  of  transportability, 
that  is,  tasks  that  are  not  necessarily  being  evaluated  in  terms  of  one  another  and  are 
otherwise  dissimilar  can  be  compared  using  a  well-anchored  scale.  Another  option  for 
subjectively  grading  dimensions  is  to  use  a  scale  such  as  High,  Medium,  Low,  and  None. 
This  scale  would  be  adequate  in  circumstances  where  the  only  comparison  of  tasks  that  is 
of  interest  is  between  two  or  more  tasks  that  are  generally  being  evaluated  in  terms  of  one 
another,  and  are  otherwise  similar.  Grading  using  this  scale  is  rather  arbitrary,  depending 
on  the  grader’s  definition  of  the  level,  so  its  transportability  is  low. 

c.  Example 

A  simple  example  of  uncertainty  would  involve  an  AW  ACS  operator 
dealing  with  unknown  air  tracks.  Since  the  identification  and  intentions  of  the  aircraft  are 
not  known  (incomplete  information  on  states,  inputs,  and  environments),  the  AWACS 
operator  is  unsure  whether  to  direct  that  the  aircraft  be  shot  down,  warn  it  away,  or  let  it 
continue  what  it  is  doing  (incomplete  information  on  outcomes).  This  task  would  be 
graded  as  Medium  or  High  uncertainty. 
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2. 


Time  Pressure 


a.  Definition 

Time  pressure  is  the  amount  of  activity  that  must  be  completed  within  a 
given  amount  of  time  (Ben  Zur  and  Breznitz,  1981,  p.  89).  Alternately,  it  could  be 
defined  as  the  degree  to  which  an  individual  or  group  performing  a  task  are  stressed  by 
the  requirement  to  complete  the  task  within  a  given  amount  of  time.  I  chose  time  pressure 
as  a  dimension  rather  than  Davis  et  al.’s  (1991)  task  characteristic  “time  frame,”  because 
time  frame  does  not  take  into  account  the  magnitude  of  the  task  at  hand,  while  time 
pressure,  being  measured  as  a  rate,  does. 

b.  Levels 

Time  pressure  could  be  either  represented  using  a  subjective  scale,  such  as 
High,  Medium,  Low,  or  None,  or  an  anchored  scale,  or  a  more  objective,  quantitative 
scale,  depending  on  the  variation  of  the  above  definition  that  is  being  used.  A  subjective 
scale  would  suggest  itself  if  comparing  two  or  more  dissimilar  tasks,  and  the  only 
information  the  researcher  is  interested  in  is  whether  there  is  time  pressure  on  the  task 
performer  to  complete  the  task  within  a  certain  period  of  time,  and  what  the  relative 
levels  between  the  two  or  more  tasks  are.  A  quantitative  scale  would  suggest  itself  when 
comparing  tasks  which  are  similar  in  most  dimensions.  Time  pressure  could  then  be 
represented  as  the  number  of  activities  or  subtasks  that  must  be  completed,  divided  by  the 
time  available  to  complete  the  task.  This  method,  unfortunately,  requires  a  standard 
definition  of  activity  or  subtask,  both  in  magnitude  and  duration.  If  two  tasks  are  equal  in 
the  quantitative  measure  of  time  pressure  described  above,  but  one  task’s  subtasks  or 
activities  take  significantly  longer  to  perform  than  the  other  task’s,  then  the  quantitative 
scale  is  inappropriate.  In  situations  where  the  grader  cannot  with  confidence  equate  the 
subtasks  or  activities  of  one  task  with  those  of  another,  time  pressure  should  be  graded 
using  the  subjective  scale. 
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c.  Example 

An  example  of  time  pressure  from  the  Persian  Gulf  conflict  is  a  mobile 
SCUD  missile  launcher,  spotted  setting  up  and  preparing  to  fire.  The  identification 
information  must  be  passed  from  the  sensor  to  a  control  agency  with  the  assets  on  hand  to 
destroy  the  launcher,  an  asset  must  be  assigned  to  destroy  the  launcher,  the  asset  must 
travel  to  the  launcher,  and  the  asset  must  destroy  the  launcher,  all  in  a  matter  of  a  few 
minutes*.  This  task  has  High  time  pressure,  on  a  subjective  scale.  On  an  objective  scale,  if 
identifying,  passing  information,  assigning  an  asset,  getting  in  position  to  attack,  and 
attacking  are  all  considered  subtasks,  and  the  time  available  is  10  minutes,  then  time 
pressure  is  5/10  or  0.5  subtasks  per  minute. 

3.  Complexity 

I  chose  a  variation  on  Campbell’s  (1988)  definition  of  complexity  over  Wood’s 
(1986),  for  several  reasons.  First,  Campbell’s  four  characteristics  of  complexity  are  more 
easily  understood  than  Wood’s  three  components  of  complexity,  and  are  more  simply 
measurable.  Second,  Wood’s  description  of  coordinative  complexity  is  very  close  to 
Malone  and  Crowston’s  (1994)  definition  of  coordination,  which  I  chose  to  include  as  a 
separate  dimension  listed  in  paragraph  four  below.  Finally,  Wood’s  concept  of  dynamic 
complexity  is  generalizable  to  all  dimensions  of  task  structure,  not  just  complexity,  and  it 
is  included  as  dynamicity,  in  paragraph  nine  below. 

Complexity,  then,  can  be  defined  as  the  degree  to  which  a  task  contains  five  task 
characteristics;  multiple  attributes,  multiple  paths,  multiple  outcomes,  conflicting 
interdependence  among  outcomes,  and  uncertain  or  probabilistic  linkages  (Campbell, 
1988,  p.  43).  Multiple  attributes  has  been  added  to  Campbell’s  original  list  of  four 
characteristics  on  the  basis  of  other  articles.  Specific  definitions  of  the  five  task 
characteristics  are  as  follows: 


’This  was  rarely,  if  ever,  successfully  done  during  the  Persian  Gulf  conflict. 
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Multiple  Attributes 


a. 


(1)  Definition.  The  number  of  attributes  that  a  task  performer 
must  take  into  account,  or  more  than  one  thing  that  must  be  taken  into  consideration  in 
order  to  complete  the  task,  directly  affect  task  complexity.  The  more  attributes  a  task  has, 
the  more  complex  it  is. 

(2)  Levels.  Multiple  attributes  is  graded  by  the  number  of 
attributes  that  must  be  taken  into  consideration. 

b.  Multiple  Paths 

(1)  Definition.  The  number  of  paths  that  could  be  taken  to  arrive 
at  a  desired  outcome  (Campbell,  1988,  p.  43). 

(2)  Levels.  This  aspect  of  complexity  is  graded  by  the 
approximate  number  of  paths  that  could  be  taken  to  arrive  at  the  desired  endstate.  In 
many  cases,  this  ntunber  could  be  infinite,  or  approach  infinity.  When  this  is  true,  the 
evaluator  should  only  count  the  major  variations  of  paths. 

c.  Multiple  Outcomes 

(1)  Definition.  The  number  of  outcomes  desired  from  a  task. 

These  outcomes  need  not  be  mutually  exclusive  (Campbell,  1988,  p.  43).  • 

(2)  Levels.  This  aspect  is  graded  by  the  number  of  different 
outcomes  that  the  task  performer  needs  to  achieve. 

d.  Conflicting  Interdependence  Among  Outcomes 

(1)  Definition.  Conflicting  interdependence  among  outcomes  is  a 
negative  relationship  between  desired  outcomes.  If  achieving  one  desired  outcome 
conflicts  with  achieving  another  desired  outcome,  complexity  increases  (Campbell,  1988, 
P-  44). 
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(2)  Levels.  Conflicting  interdependence  among  outcomes  can  be 
graded  by  counting  the  number  of  conflicts  between  instances  of  subparagraph  (c)  above. 
Each  conflict  should  then  be  given  a  grade  of  1  if  the  conflict  is  minor,  2  if  it  is  moderate, 
and  3  if  it  is  severe,  or  some  similar  scale.  These  grades  should  then  be  totaled  across  all 
conflicts  so  that  each  task  has  a  single,  numerical  grade. 

e.  Uncertain  or  Probabilistic  Linkages 

(1)  Definition.  The  condition  where  the  connection  between  the 
potential  path  activities  and  the  desired  outcomes  from  a  task  are  uncertain,  or 
probabilistic  (Campbell,  1988,  p.  45). 

(2)  Levels.  High,  Medium,  Low,  or  None. 

f.  Example 

A  good  general  example  of  complexity  is  the  conduct  of  an  amphibious 
assault.  The  amphibious  assault  task  contains  multiple  attributes  (terrain,  hydrography, 
enemy  positions,  roads,  beaches,  enemy  reinforcement  capability,  etc.)  One  desired 
outcome  of  the  task  is  to  destroy  or  suppress  enemy  positions  at  or  near  the  beaehhead. 
There  are  several  ways  to  do  this  {multiple  paths),  such  as  to  use  close  air  support,  naval 
gunfire,  infiltrate  SEAL  or  reconnaissance  teams,  or  some  combination.  There  are  also 
many  additional  outcomes  {multiple  outcomes)  that  are  desired,  such  as  to  achieve 
surprise  and  minimize  casualties.  However,  achieving  surprise  and  destroying  and 
suppressing  enemy  positions  are  usually  mutually  exclusive  {conflicting  interdependence 
among  paths)  —  if  the  commander  precedes  his  amphibious  assault  with  a  heavy  air  and 
sea  bombardment,  he  will  stand  a  good  ehance  of  destroying  or  suppressing  the  enemy 
positions,  but  he  will  probably  destroy  the  element  of  surprise.  Finally,  if  the  enemy’s 
positions  at  or  near  the  beach  are  well  protected  and  disguised,  the  commander  is 
uncertain  whether  his  possible  actions  of  close  air  support,  naval  surface  fire  support,  etc. 
will  be  able  to  successfully  aehieve  his  desired  outcome  of  suppressing  or  destroying  the 
enemy  positions  {uncertain  or  probabilistic  linkages). 
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This  example  would  be  graded  as  follows; 


(1)  Multiple  Attributes:  The  task  attributes  that  must  be 
considered  in  an  amphibious  assault  are  objective,  time  available,  terrain,  weather, 
hydrography,  friendly  forces  available,  enemy  positions,  enemy  reinforcements,  enemy 
air  threat,  enemy  sea  threat,  enemy  anti-air  threat,  beaches,  mobility  on  land,  and 
non-combatants,  for  a  total  of  14.  These  are  very  high-level  attributes,  so  it  would  be 
inappropriate  to  compare  this  task  with  a  task  in  which  the  attributes  were  low-level. 

(2)  Multiple  Paths:  The  number  of  paths  that  could  be  taken  to 
conduct  an  amphibious  assault  is  infinite.  They  can  be  categorized  into  major  variations, 
however.  The  major  paths  that  could  be  taken  are  to  conduct  the  assault  (as  an 
across-the-beach  assault,  vertical  envelopment,  or  combination)  with  extensive  air  and 
naval  surface  fire  support  beaeh  preparation,  conduct  the  assault  without  extensive  air  and 
naval  surface  fire  support  beach  preparation,  conduct  the  assault  while 
destroying/suppressing  enemy  positions  using  stealthy  means  (SEAL/Recon 
teams/information  Warfare),  or  any  of  the  three  previously  mentioned  paths,  plus  a  feint 
at  a  different  location,  for  a  total  of  6  possible  major  paths. 

(3)  Multiple  Outcomes:  High-level  desired  outcomes  for  the 
given  amphibious  assault  task  are  to  (a)  accomplish  the  objective,  (b)  achieve  surprise,  (c) 
suppress  enemy  positions  at  the  beach,  (d)  minimize  casualties,  (e)  interdict  enemy 
reserves,  (f)  achieve  sea  supremacy,  (g)  achieve  air  superiority,  and  (h)  minimize 
collateral  damage,  for  a  total  of  8  desired  outcomes. 

(4)  Conflicting  Interdependence  Among  Outcomes:  Conflicts, 
and  the  scores  for  each,  are  shown  in  Table  1  (correlate  letters  on  table  with  outcomes 
listed  in  paragraph  above).  It  should  be  noted  that  the  scoring  in  Table  1  is  situationally 
dependent;  conflicts  between  outcomes  would  vary  in  different  amphibious  operations. 
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0 

0 
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11 

31 

Table  1.  Scoring  of  Conflicting  Interdependence  Among  Outcomes,  Where  Each  Entry  On  Table 
Represents  The  Conflict  Between  The  Outcomes  Represented  in  Column  i  and  Row  j 


(5)  Uncertain  or  Probabilistic  Linkages:  Depending  on  the 
situation  and  the  accuracy  and  volume  of  intelligence  available,  this  could  vary  from  low 
to  high. 


4.  Coordination  Requirements 
a.  Definition 

Generally,  coordination  requirements  is  the  degree  to  which  dependencies 
between  activities  must  be  managed  (Malone  and  Crowston,  1994,  p.  90).  This  can  be 
subdivided  into  external  (the  group  with  others)  and  internal  (among  members  of  the 
group)  coordination.  Four  different  types  of  dependencies  that  must  be  coordinated,  and 
an  example  of  each,  are  as  follows: 

(1)  Shared  Resources.  Who,  among  a  group  of  actors,  gets  which 
available  and  common  resources  (Malone  and  Crowston,  1994,  p.  92). 

(2)  Producer/Consumer  Relationships.  When  one  member  of  a 
group  uses  the  output  of  another,  or  a  member  of  a  group  or  the  group  as  a  whole  uses  the 
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output  of  another  entity,  or  this  other  entity  uses  the  group’s  or  a  member  of  the  group’s 
output  (Malone  and  Crowston,  1994,  p.  93). 

(3)  Simultaneity  Constraints.  When  two  or  more  activities  must  be 
scheduled  or  synchronized  (Malone  and  Crowston,  1994,  p.  95). 

(4)  Task/Subtask.  Goal  selection  and/or  task  decomposition 
within  a  group  and/or  among  groups  (Malone  and  Crowston,  1994,  p.  95). 

b.  Levels 

A  task  would  be  given  a  grade  for  each  of  the  four  different  types  of 
dependencies  listed  above,  and  on  both  the  internal  and  external  level.  Subjective  grades 
such  as  High,  Medium,  Low,  and  None  are  probably  most  appropriate.  Thus,  each  task 
would  have  eight  coordination  requirements  grades  associated  with  it. 

c.  Example 

(1)  Shared  resources:  Two  light  infantry  units  each  face  an  enemy 
armored  threat,  and  there  is  only  one  section  of  antitank  helicopters  that  can  be  used 
against  those  threats,  and  it  is  attached  to  one  of  the  infantry  units.  Coordination  required 
would  be  graded  as  High  (internal)  and  Low  (external).  If  the  antitank  helicopter  asset  is 
owned  by  an  external  agent,  however,  coordination  required  would  be  graded  as  Low 
(internal)  and  High  (external). 

(2)  Producer-consumer  relationships:  During  the  conduct  of  an 
amphibious  assault,  mineclearing  helicopters  must  be  used  to  clear  mines  from  the 
approach  to  the  landing  beach.  The  landing  force,  then,  is  the  consumer  of  the 
mineclearing  helicopters’  output.  If  we  consider  the  “group”  to  be  the  amphibious  task 
force,  then  coordination  required  would  be  High  (internal)  and  Low  (external).  If  we 
consider  the  “group”  to  be  the  landing  force,  however,  then  coordination  required  would 
be  Low  (internal)  and  High  (external). 


21 


(3)  Simultaneity  constraints:  During  the  latter  stages  of  the  same 
amphibious  assault,  an  infantry  unit  must  conduct  an  attack  synchronized  with  close  air 
support  and  naval  surface  fire  support.  If  the  “group”  was  considered  to  be  the 
amphibious  task  force,  the  coordination  required  would  be  High  (internal)  and  Low 
(external).  If  the  “group”  was  considered  to  be  the  landing  force,  the  coordination 
required  would  be  Low  (internal)  and  High  (external). 

(4)  Task/Subtask:  A  landing  force  commander  is  given  a  mission 
of  taking  a  specific  objective.  He  must  then  divide  the  task  up  into  subtasks  for  his 
subordinate  units  to  complete.  The  coordination  required  in  this  situation  would  be  High 
(internal)  and  Low  (external). 

5.  Magnitude 

a.  Definition 

The  magnitude  of  a  task  is  the  number  of  activities  or  subtasks  that  must 
be  performed  in  order  to  complete  the  task. 

b.  Levels 

The  magnitude  of  a  task  could  be  determined  quantitatively  by  the  number 
of  activities  that  must  be  performed  in  order  to  complete  the  task.  However,  this  requires 
a  standardized  definition  of  “activity,”  such  that  one  activity  is  as  difficult  to  perform  as 
another,  and  decomposition  of  the  task  to  the  point  where  all  activities  are  identified. 
Another  way  to  assess  the  magnitude  of  a  task  would  be  to  use  an  anchored  scale.  For 
example,  magnitude  could  be  measured  on  a  one  to  one  hundred  scale,  with  “one” 
representing  the  task  of  pressing  the  spacebar  on  a  typev^riter,  and  “one  hundred” 
representing  the  task  of  constructing  the  United  States  Interstate  Highway  System. 

c.  Example 

The  task  of  conducting  an  amphibious  assault  has  many  different  activities 
or  subtasks  that  must  be  performed,  such  as  clearing  the  beach,  making  a  reconnaissance. 
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suppressing  artillery  with  close  air  support,  et  cetera.  On  the  one  to  one  hundred  scale 
mentioned  above,  the  score  would  be  about  30  for  a  significant  amphibious  assault. 

6.  Resources  Required 

a.  Definition 

Resources  required  to  complete  a  task  is  defined  as  the  resources  other 
than  information  that  the  actors  must  possess  in  order  to  successfully  complete  the  task  in 
question. 


b.  Levels 

Resources  required  could  be  measured  quantitatively  by  the  number  of 
resources  required  to  complete  a  task,  or  could  be  graded  on  a  subjective  “High,  Medium, 
and  Low”  scale.  As  is  the  case  with  magnitude,  one  must  take  care  to  ensure  that  there  is 
a  standard  definition  of  resource,  so  that  five  resources  in  one  instance  is  the  same  as  five 
resources  in  another. 


c.  Example 

A  landing  force  is  given  the  mission  of  attacking  an  objective,  and  that 
objective  requires  three  infantry  companies  to  effectively  overwhelm  it.  If  the  “base  unit” 
of  resources  is  one  infantry  company  equivalent,  then  resources  required  to  complete  this 
task  is  three. 

7.  Information  Required 

a.  Definition 

Information  required  to  complete  a  task  is  the  information  that  the  actors 
must  possess  in  order  to  successfixlly  complete  the  task  in  question. 

b.  Levels 

Information  required  is  measured  using  the  same  method  as  resources 

required. 
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c.  Example 

A  Silkworm  anti-ship  missile  site  threatens  an  aircraft  carrier  battle  group. 
However,  it  was  reported  in  a  residential  area,  so  additional  information  (confirmation 
and  precise  location  via  U-2  imagery)  is  required  before  the  commander  can  destroy  that 
threat.  If  the  base  unit  of  information  is  one  intelligence  report,  then  information  required 
to  complete  this  task  is  two  reports,  the  initial  report  and  the  confirmation  report. 

8.  Task  Formalization 

a.  Definition 

Task  formalization  is  the  level  of  specification  and  structure  exhibited  by 
the  task  (Davis  et  al.,  1991,  p.  22).  A  task  with  high  formalization  is  defined  in  a  very 
structured  way;  there  are  certain  well-defined  activities  that  must  be  performed  in  a 
definite  sequence  in  order  to  complete  the  task.  In  a  task  with  low  formalization,  though, 
the  activities  required  to  complete  the  task,  and  possibly  even  the  goals  of  the  task,  are 
poorly  defined  and  open  to  interpretation. 

b.  Levels 

This  dimension  is  again  quite  subjective,  and  the  levels  should  probably  be 
High,  Medium,  Low,  and  None,  or  some  other  discrete  scale. 

c.  Example 

The  task  of  calling  for  artillery  fire  against  a  visible  target  is  very  well 
structured.  There  are  precise  procedures  that  the  forward  observer  must  follow,  using 
specific  radio  nets  and  message  formats,  that  are  ingrained  from  his  earliest  training.  Task 
formalization  for  an  artillery  call  for  fire  is  High.  However,  the  task  of  infiltrating  enemy 
lines  and  destroying  a  prepared  defensive  position  is  not  well  structured  —  there  are 
many  ways  that  the  task  could  be  carried  out,  and  the  methods  used  and  paths  taken  are 
not  well  formalized,  but  situationally  dependent.  Task  formalization  for  the  infiltration 
task  is  Low. 
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9.  Dynamicity 


a.  Definition 

The  dynamicity  of  a  task  is  the  degree  to  which  one  or  more  of  the 
dimensions  of  the  task  changes  over  time.  Dynamicity  could  refer  to  any  of  the 
dimensions  described  above,  alone  or  in  combination  with  others. 

b.  Levels 

This  is  quite  subjective,  and  would  probably  best  be  graded  as  High, 
Medium,  Low  or  None  in  each  dimension,  or  possibly  the  number  of  changes  per  unit 
time  in  each  dimension,  if  that  is  measurable. 

c.  Example 

Returning  to  our  amphibious  assault  example,  consider  the  task  of 
conducting  the  assault  across  the  beach.  If  the  assault  was  conducted  while  the 
amphibious  task  force  was  still  over  the  horizon,  and  retained  the  element  of  surprise,  the 
task  would  be  much  different  than  if  it  was  conducted  later,  when  the  amphibious  task 
force  was  in  view  of  the  objective  beach,  and  the  element  of  surprise  was  lost.  The  later  it 
was  conducted,  the  better  prepared  the  enemy  would  be  for  the  assault.  In  each 
dimension,  dynamicity  is  graded  as  follows: 

Uncertainty:  High  (The  later  the  assault  is  conducted,  the  less  uncertainty) 

Time  Pressure:  High  (The  later  the  assault  is  conducted,  the  more  time  pressure) 
Complexity:  High  (The  later  the  assault  is  conducted,  the  more  complexity) 
Coordination  Requirements:  High  (The  later  the  assault  is  conducted,  the  more 
coordination  required) 

Magnitude:  High  (The  later  the  assault  is  conducted,  the  greater  the  magnitude) 
Resources  Required:  High  (The  later  the  assault  is  conducted,  the  more  resources 
required) 

Information  Required:  High  (The  later  the  assault  is  conducted,  the  more 
information  required) 
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Task  Formalization:  Low 


D.  EXCEPTIONS  TO  ORTHOGONALITY 

The  dimensions  described  in  the  preceding  section  are  distinct,  but,  unfortunately, 
related.  However,  if  the  interrelations  between  dimensions  are  known,  compensation  for 
the  interaction  can  be  made  in  order  to  keep  dimensions  the  experimenter  wants  to  remain 
constant  from  varying.  This  section  will  discuss  how  one  might  expect  changes  in  one 
dimension  to  affect  all  other  dimensions. 

There  should  be  little  or  no  interaction  between  uncertainty  and  dynamicity,  time 
pressure  and  dynamicity,  complexity  and  dynamicity,  coordination  requirements  and  task 
formalization,  coordination  requirements  and  dynamicity,  magnitude  and  task 
formalization,  magnitude  and  dynamicity,  resources  required  and  task  formalization, 
resources  required  and  dynamicity,  information  required  and  task  formalization, 
information  required  and  dynamicity,  or  task  formalization  and  dynamicity.  All  other 
interactions  are  detailed  below. 

1.  Uncertainty-Time  Pressure 

As  uncertainty  increases,  the  number  of  activities  that  an  actor  would  have  to 
perform  in  order  to  deal  with  the  uncertainty  well  enough  to  complete  the  task  could  also 
increase  (increased  magnitude).  If  this  number  of  activities  increases  while  the  time 
allowed  to  perform  the  task  remains  constant,  time  pressure  will  increase.  Conversely,  if 
time  pressure  increases,  it  could  force  the  actor  to  complete  the  task  before  he  is  able  to 
obtain  all  the  information  he  wants,  thus  increasing  uncertainty. 

2.  Uncertainty-Complexity 

As  uncertainty  increases,  complexity  can  also  increase.  The  number  of  attributes 
that  must  be  taken  into  account  in  order  to  reduce  uncertainty  can  increase,  thus  causing 
greater  complexity.  Additionally,  if  the  uncertainty  decreases  the  probability  of  the 
linkages  between  path  activities  and  desired  outcomes,  this  can  cause  an  increase  in 
complexity.  Conversely,  if  the  complexity  increases,  it  should  not  necessarily  affect  the 
uncertainty. 


26 


3.  Uncertainty-Coordination  Requirements 

Changes  in  uncertainty  can  cause  changes  in  coordination  requirements.  If 
uncertainty  increases,  whether  resources  must  be  shared,  which  activities  must  be 
simultaneous,  what  must  be  produced  and  consumed,  or  which  subtasks  are  required  in 
the  performance  of  a  task  can  also  become  more  uncertain,  requiring  greater  coordination 
for  any  type  of  dependency  in  which  the  uncertainty  is  increased.  Conversely,  changes  in 
coordination  requirements  should  not  cause  changes  in  uncertainty. 

4.  Uncertainty-Magnitude 

As  mentioned  under  “time  pressure,”  as  uncertainty  increases,  the  number  of 
activities  that  an  actor  must  perform  in  order  to  alleviate  the  uncertainty  could  increase, 
thus  increasing  the  magnitude  of  the  task.  Conversely,  an  increase  in  magnitude  could 
force  the  actor  to  complete  the  task  before  he  is  able  to  obtain  all  the  information  he 
wants,  thus  increasing  imcertainty. 

5.  Uncertainty-Resources  Required 

As  uncertainty  increases,  resources  required  could  increase,  if  those  resources 
would  be  used  to  decrease  the  imcertainty  or,  in  a  case  that  involves  two  or  more  uses  for 
certain  resources,  the  uncertainty  is  enough  so  that  the  decisionmaker  desires  to  use 
resources  for  all  potential  paths,  in  order  to  “cover  all  bets.”  An  increase  in  resources 
required  would  not  tend  to  drive  an  increase  in  uncertainty,  however. 

6.  Uncertainty-Information  Required 

As  uncertainty  increases,  information  required  could  also  increase,  because  the 
decisionmaker  would  want  more  information  in  order  to  reduce  his  uncertainty.  Changes 
in  information  required,  though,  should  not  cause  changes  in  uncertainty. 

7.  Uncertainty-Task  Formalization 

Increases  in  uncertainty  could  also  elicit  increases  in  task  formalization,  since  the 
uncertainty  can  involve  the  structure  and  paths  taken  to  complete  the  task.  This  is  not 
necessarily  so,  however;  a  task  can  still  be  highly  formalized  and  well  structured  if  some 
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or  many  of  the  states,  inputs,  outcomes,  or  environments  are  not  well  known.  Changes  in 
task  formalization  should  not  drive  changes  in  uncertainty,  however. 

8.  Time  Pressure-Complexity 

Changes  in  time  pressure  can  cause  changes  in  complexity.  If  the  time  pressure 
decreases,  the  number  of  attributes  or  paths  that  can  be  considered  can  increase,  because 
of  the  additional  time  the  decisionmaker  has  to  consider  them.  Also,  uncertain  or 
probabilistic  linkages  can  decrease  if  time  pressure  decreases,  because  the  decisionmaker 
has  additional  time  to  reduce  his  uncertainty.  Conversely,  changes  in  complexity  can 
cause  changes  in  time  pressure.  If  complexity  decreases,  the  amount  of  time  that  the 
decisionmaker  must  devote  to  sorting  out  the  situation  also  decreases,  and,  if  the  amount 
of  time  available  remains  constant,  time  pressure  will  decrease. 

9.  Time  Pressure-Coordination  Requirements 

Changes  in  time  pressure  can  affect  coordination  requirements.  If  the  time 
pressure  increases,  coordination  between  two  or  more  entities  can  become  more  difficult, 
or  even  impossible,  because  the  time  available  to  communicate  and  synthesize  is 
lessened.  Conversely,  changes  in  coordination  requirements  can  cause  changes  in  time 
pressure.  If  coordination  requirements  are  lessened,  the  amount  of  activities  that  must  be 
performed  is  generally  lessened,  because  some  of  those  activities  are 
coordination-related,  such  as  the  actors  communicating  with  one  another.  Lessening  the 
number  of  activities  while  holding  the  time  available  constant  reduces  time  pressure. 

10.  Time  Pressure-Magnitude 

Since  time  pressure  and  magnitude  are  directly  related  (time  pressure  is 

magnitude  divided  by  time  available),  changes  in  one  will  cause  changes  in  the  other, 
unless  the  time  available  is  modified  accordingly. 

11.  Time  Pressure-Resources  Required 

Changing  time  pressure  would  tend  to  have  an  inverse  effect  on  resources 
required.  If  time  pressure  was  increased,  the  resources  required  would  tend  to  go  down. 
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because  the  actors  would  not  have  time  to  use  all  the  resources  that  are  available  to  them. 
Changes  in  resources  required  would  tend  to  have  a  direct  effect  on  time  pressure  —  if 
resources  required  was  increased,  then  time  pressure  would  increase,  because  of  the 
additional  activities  that  would  probably  be  required  to  put  those  resources  to  use,  as  long 
as  time  available  is  held  constant. 

12.  Time  Pressure-Information  Required 

This  interaction  should  be  the  same  as  the  time  pressure-resources  required 
interaction. 

13.  Time  Pressure-Task  Formalization 

As  time  pressure  is  increased,  task  formalization  would  tend  to  increase,  in  those 
instances  where  there  is  a  more  structured  way  to  perform  a  task  that  may  not  achieve  the 
goals  of  the  decisionmaker  as  well  as  a  less  structured  method  will,  but  the  more 
structured  method  would  tend  to  take  more  time.  As  task  formalization  is  increased,  time 
pressure  would  tend  to  decrease,  because  more  formalized  tasks  would  tend  to  take  less 
time  because  of  the  well-defined  nature  of  the  activities  involved. 

14.  Complexity-Coordination  Requirements 

Complexity  and  coordination  requirements  can  affect  each  other  in  many  subtle 
ways.  For  instance,  if  the  number  of  possible  paths  is  increased,  coordination 
requirements  could  be  increased,  because  of  a  possible  requirement  to  coordinate  with 
other  team  members  in  order  to  explore  the  paths.  Or,  increasing  a  shared  resources 
requirement  could  increase  the  number  of  possible  paths  that  could  be  taken.  Changes  to 
either  of  these  dimensions  must  be  scrutinized  carefully  to  ensure  any  effect  on  the  other 
has  been  accounted  for. 

15.  Complexity-Magnitude 

Increasing  complexity  can  increase  the  magnitude  of  a  task.  If,  for  instance, 
additional  activities  must  be  performed  in  order  to  resolve  a  complex  issue,  then 
magnitude  will  increase.  Additionally,  if  the  magnitude  of  a  task  changes,  and  the  added 
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or  decreased  activities  affect  the  number  of  attributes,  paths,  outcomes,  interdependence, 
cues,  or  linkages  present,  then  the  complexity  could  increase  or  decrease  as  wfell. 

16.  Complexity-Resources  Required 

Increasing  complexity  of  a  task  might  require  a  different  system  or  more 
personnel  to  aid  in  problem-solving  than  a  more  simple  task  would,  thus  increasing 
resources  required.  If  resources  required  to  complete  a  task  were  decreased,  then 
complexity  could  decrease  also,  because  the  decrease  in  resources  required  could  result  in 
fewer  attributes  or  paths  that  must  be  considered  by  the  decisionmaker. 

17.  Complexity-Information  Required 

Increasing  the  complexity  of  a  task  could  increase  information  required,  because 
the  decisionmaker  might  want  more  information  in  order  to  help  choose  the  right  path,  or 
decrease  uncertainty  of  linkages  between  paths  and  outcomes.  Increasing  the  information 
required  could  also  increase  task  complexity,  because  the  additional  information  required 
could  be  an  additional  attribute  that  the  decisionmaker  must  consider. 

18.  Complexity-Task  Formalization 

Increasing  complexity  can  decrease  task  formalization.  As  the  number  of 
attributes,  paths,  and  desired  outcomes  grows,  the  chore  of  formalizing  a  task  can  become 
more  difficult,  such  that  many  extremely  complex  tasks  are  not  formalized  at  all,  because 
of  the  number  of  characteristics  that  must  be  considered.  Increasing  task  formalization 
may  or  may  not  increase  complexity.  Increasing  formalization  and  adding  a  structured 
way  of  looking  to  the  decisionmaking  process  could  have  the  effect  of  decreasing 
complexity,  or  at  least  making  the  complexity  more  easily  manageable. 

19.  Coordination  Requirements-Magnitude 

Increasing  coordination  requirements  could  increase  the  magnitude  of  a  task, 
because  greater  coordination  requirements  could  result  in  additional  activities  that  must 
be  performed  in  order  to  coordinate  actions.  Changes  in  task  magnitude,  however,  should 
have  little  or  no  effect  on  coordination  requirements,  vmless  the  activities  that  were  added 
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or  deleted  specifically  involve  use  of  shared  resources,  a  producer/consumer  relationship, 
a  simultaneity  constraint,  or  the  task  must  be  decomposed  into  subtasks  by  the 
decisionmakers. 

20.  Coordination  Requirements-Resources  Required 

Changes  to  the  coordination  requirements  should  not  affect  resources  required  to 
perform  a  task.  Increases  in  resources  required,  though,  could  cause  coordination 
requirements  to  increase,  because  the  additional  resources  required  could  cause  a 
necessity  to  share  available  resources  where  one  did  not  exist  before,  unless  the  resources 
available  were  also  increased. 

21.  Coordination  Requirements-Information  Required 

Changes  to  coordination  requirements  should  not  affect  information  required. 
Increases  in  information  required  could  lead  to  increases  in  coordination  requirements, 
because  the  decisionmakers  might  need  to  coordinate  actions  in  order  to  obtain  the 
additional  information. 

22.  Magnitude-Resources  Required 

Changes  in  the  magnitude  of  a  task  should  not  affect  resources  required  to 
complete  a  task,  unless  the  added  activities  require  more  resources  to  perform  them. 
Changes  in  resources  required,  however,  could  change  the  magnitude  of  a  task,  if  the 
additional  resources  needed  additional  activities  to  be  performed  in  order  to  put  the  new 
resources  to  use. 

23.  Magnitude-Information  Required 

Changes  in  the  magnitude  of  a  task  should  not  affect  information  required  to 
complete  a  task,  unless  the  added  activities  require  more  information  in  order  to  perform 
them.  Changes  in  the  information  required,  however,  could  change  the  magnitude  of  a 
task,  if  the  actors  had  to  perform  additional  activities  in  order  to  obtain  the  added 
information. 
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24.  Resources  Required-Information  Required 

Changes  in  resources  required  to  complete  a  task  could  cause  changes  in 
information  required,  if  the  additional  resources  needed  additional  information  in  order  to 
put  the  resources  to  use.  Conversely,  changes  in  information  required  to  complete  a  task 
could  result  in  changes  in  resources  required,  if  the  new  information  requirement  needed 
additional  resources  in  order  to  obtain  the  information. 

E.  SUMMARY 

The  purpose  of  this  chapter  was  to  enumerate  dimensions  of  task  structure,  define 
them,  and  develop  a  method  of  grading  the  dimensions,  so  these  dimensions  can  be  held 
constant  or  varied  in  an  experimental  environment.  The  chapter  began  with  a  review  of 
the  pertinent  literature,  surveying  the  possible  sources  of  information  and  different 
opinions  on  dimensions  of  task  structure.  These  dimensions  were  then  compiled,  revised, 
and  extended  into  what  the  author  believes  is  a  comprehensive  breakdown  of  the 
dimensions  of  task  structure.  A  summary  of  these  dimensions,  and  the  levels  at  which 
they  can  be  graded,  is  included  in  Table  2  below. 

Examples  of  each  dimension  were  then  given,  and  graded  using  the  scale  that  was 
developed.  Finally,  the  author  described  exceptions  to  the  requirement  that  the 
dimensions  be  orthogonal  to  one  another,  to  aid  in  adjusting  for  any  effect  changing  one 
dimension  might  have  on  other  dimensions. 
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Dimension 

Uncertainty 
Time  Pressure 


Complexity 

-  Multiple  Attributes 

-  Multiple  Paths 

-  Multiple  Outcomes 

-  Conflicting  Interdependence  Among 
Outcomes 

-  Uncertain  or  Probabilistic  Linkages 

Coordination  Requirements 

-  Shared  Resources 

-  Producer/Consumer  Relationships 

-  Simultaneity  Constraints 

-  Task/Subtask 


Levels 

High,  Medium,  Low,  None 

High,  Medium,  Low,  None 
Magnitude/Time  Available) 


Number  of  attributes 
Number  of  paths 
Number  of  outcomes 
Number  of  conflicts,  levels  of  each, 
totaled  for  task 
High,  Medium,  Low,  None 

For  all  types  of  dependencies: 

High,  Medium,  Low,  None,  for  internal 
and  external  coordination 


(or 


Magnitude 
Resources  Required 
Information  Required 
Task  Formalization 
Dynamicity 


Number  of  activities  or  subtasks 

Number  of  resources  required 

Number  of  pieces  of  information  required 

High,  Medium,  Low 

High,  Medimn,  Low  for  each  dimension 


Table  2.  Dimensions  of  Task  Structure 
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III.  TASK  STRUCTURE  DIAGRAM  AND  TASK  DESIGN  PROCESS 


A.  INTRODUCTION 

As  discussed  in  the  previous  chapter,  determination  of  the  dimensions  of  task 
structure  is  an  important  aspect  of  experimental  design  involving  task  structure,  since  it 
provides  the  groundwork  for  varying  or  controlling  tasks  based  on  dimensions.  Once 
those  dimensions  are  defined,  it  would  be  of  further  assistance  to  the  experimenter  to 
develop  a  method  for  visually  describing  the  task  structure,  flow,  and  as  many  of  the 
dimensions  defined  in  the  previous  chapter  as  possible.  A  visual  method  of  this  sort 
would  make  the  undertaking  of  causing  tasks  to  differ  or  remain  constant  in  various 
respects  simpler. 

The  focus  of  this  chapter  is  the  development  of  a  task  structure  diagram  concept. 
First,  I  will  give  some  preliminary  definitions  necessary  to  the  discussion  of 
decomposition  of  tasks  into  component  subtasks  and  actions.  I  will  then  describe  the  task 
structure  diagram  that  I  developed,  and  define  the  specific  features  and  capabilities  of  the 
diagram.  Then,  I  will  describe  how  the  dimensions  of  task  structure  developed  in  the 
previous  chapter  relate  to  the  diagram.  Finally,  I  will  synthesize  the  concepts  of  Chapter 
II  and  this  chapter  into  a  task  design  process  that  can  be  used  to  develop  a  military 
operational  scenario,  or  more  general  task,  in  an  experimental  context. 

B.  DEFINITIONS 

Because  the  development  of  a  task  structure  diagram  will  involve  decomposing 
tasks  into  the  smaller  activities  of  which  they  are  constituted,  it  is  necessary  to  define 
exactly  what  those  different  activities  should  be  called,  and  to  define  task  structure  and 
the  task  structure  diagram.  These  definitions  apply  throughout  this  thesis. 

1.  Activity 

An  activity  is  any  act  that  must  be  performed,  at  a  high  or  low  level  of  task 
decomposition.  For  our  purposes,  it  is  a  generic  term  encompassing  tasks,  subtasks,  and 
actions. 
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2. 


Task 


A  task  is  the  macro  level  activity.  It  describes  the  overall  activity  that  is  being 
performed  by  the  actors.  Since  it  is  really  impossible  to  define  beforehand  the  magnitude 
of  the  task,  for  our  purposes,  it  is  defined  as  the  level  that  is  the  primary  focus  of  the 
study. 

3.  Subtask 

A  subtask  is  a  next-lower  level  component  of  a  task.  The  nodes  on  a  task  structure 
diagram  are  subtasks.  There  can  be  more  than  one  level  of  subtasks;  if  there  are  multiple 
layers,  the  highest  layer  of  subtasks  is  subtask  level  1. 

4.  Action 

Actions  are  activities  that  are  in  their  most  elemental  state  for  the  uses  of  the 
study.  Actions  are  either  not  further  decomposible,  or  further  decomposition  would  be 
impractical  or  would  serve  no  purpose. 

5.  Task  Structure 

Task  structure  is  defined  as  the  flow  of  subtasks  within  a  task  in  the  time  domain. 

6.  Task  Structure  Diagram 

A  task  structure  diagram  is  a  visual  model  of  a  task  which  describes  the  task 
structure,  and  as  many  characteristics  of  a  task  as  practical.  The  task  structure  diagram  is 
designed  to  simplify  understanding  of  the  task  and  manipulation  of  potential  variables. 

C.  TASK  STRUCTURE  DIAGRAM 

The  task  structure  diagram  I  developed  is  based  loosely  on  the  data  flow  diagram 
(DFD)  concept  (Hatley  and  Pirbhai,  1988,  p.  13).  The  purpose  of  this  task  structure 
diagram  is  to  provide  a  visual  representation  of  the  flow  of  subtasks  and  actions,  possible 
paths,  simultaneity  constraints,  competition,  prerequisites,  resources  and  information 
required,  decomposability,  and  dynamicity  of  subtasks  within  a  task  to  experimental 
designers.  Many  of  the  dimensions  of  task  structure  in  the  previous  chapter  are 
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represented  directly  in  this  task  structure  diagram;  others  can  be  inferred  from  it.  By 
visualizing  the  structure  of  a  task  in  this  way,  experimenters  are  more  able  to  determine  if 
that  task  accomplishes  the  objectives  that  have  been  set.  In  addition,  the  task  structure 
diagram  provides  a  straightforward,  visual  method  for  comparing  it  with  other  tasks  and 
for  describing  a  task  to  those  outside  the  scenario  design  process.  This  method  also 
enables  design  from  the  other  direction  —  experimental  designers  can  delineate  a  task 
structure  that  they  are  interested  in  testing,  and  the  scenario  can  be  written  to  conform  to 
that  structure.  It  further  promotes  the  “object  oriented”  view  of  task  structure  design, 
allowing  designers  to  rearrange  activities  and  nodes  visually,  as  modules,  to  achieve 
experimental  goals. 

Clearly,  tasks  with  high  levels  of  task  formalization,  or  highly  structured  tasks,  are 
most  easily  described  by  this  type  of  method.  As  one  moves  down  the  scale  from  high 
formalization  to  low,  the  possible  paths  that  could  be  taken  grow  exponentially,  until  a 
point  is  reached  where  the  labor  involved  in  developing  this  sort  of  diagram  outweighs 
the  benefits  to  be  gained  from  its  use.  Figure  2  is  an  example  of  the  task  structure  diagram 
developed  in  this  chapter.  The  primitives,  or  building  blocks,  of  the  proposed  method  are 
described  below. 

1.  Flow  Description 

In  this  method,  the  task  is  considered  to  encompass  the  entire  diagram;  the 
individual  subtasks  are  the  nodes,  represented  by  the  circles  or  rectangles.  The  task  flows 
in  time  from  the  “start”  box  to  the  completion  of  the  final  subtask. 

2.  Actors 

The  actor  who  is  performing  each  subtask  in  Figure  2  is  represented  by  the  style 
of  type  used  for  the  name  of  the  subtask.  If  the  subtask  is  given  in  bold  type,  then  Unit  1 
is  the  task  performer,  while  if  the  name  of  the  subtask  is  given  in  italic  type,  then  Unit  2 
is  the  task  performer.  If  the  subtask  is  in  normal  type,  then  both  actors  are  involved  in  the 
subtask.  If  there  are  more  than  two  actors  involved  in  a  task,  then  different  combinations 
and  fonts  would  have  to  be  used. 
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Task1 


Unit  1 

Unit  2 
Common 
Competitive 
I  I  Static 
Dynamic 

.  Decomposible 

Parallel  Tasks 
Or  Operator 

V _ /  And  Operator 

^ —  Hard  Prereq 
. Soft  Prereq 


Subtask  16 


Subtask  17 


Subtask  19 


Figure  2.  Task/Subtask  Level  Task  Structure  Diagram 


3.  Decomposability 

Decomposability  is  defined  as  the  ability  to  further  divide  the  task,  subtask,  or 
activity  into  lower  level  subtasks  or  actions  (Simon,  1981,  pp.  196-210). 
Decomposability  is  represented  by  the  border  of  the  rectangle  or  oval  representing  each 
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activity.  If  the  border  is  solid,  that  means  the  subtask  is  not  decomposible  —  the  task, 
subtask,  or  action  represented  is  at  its  most  basic  level.  If  the  border  is  a  dotted  line,  then 
the  activity  can  be  further  decomposed. 

4.  Simultaneity 

Simultaneity,  from  Chapter  II,  is  defined  as  the  requirement  for  two  or  more 
activities  to  be  performed  at  the  same  time  or  synchronized,  and  is  a  type  of  dependency 
between  actions  that  is  encompassed  within  the  aegis  of  coordination  requirements. 
Simultaneity  is  represented  by  a  thick  bar  connecting  the  two  activities  that  have  the 
dependency  relationship. 

5.  And  Operator 

The  And  operator  is  represented  in  the  diagram  by  a  half-moon  shape.  It 
represents  the  requirement  for  both  of  the  previous  activities  to  be  completed  before  the 
next  can  be  performed. 

6.  Or  Operator 

The  Or  operator  is  represented  in  the  diagram  by  a  crescent  shape.  It  represents 
the  requirement  for  either  one  of  the  previous  activities  to  be  completed  before  the  next 
can  be  performed. 

7.  Competition 

Whether  an  activity  is  competitive  or  non-competitive  describes  another  of  the 
coordination  requirements  dependencies,  shared  resources.  A  competitive  task  is  one  in 
which  two  or  more  actors  need  the  same  resource  to  complete  the  task.  Competition  over 
resources  is  represented  in  the  diagram  by  underlining  the  title  of  the  activity;  if  the  title 
of  the  activity  is  not  underlined,  then  there  is  no  competition  over  resources  for  that 
activity. 
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8.  Dynamicity 

Dynamicity,  from  Chapter  II,  is  the  degree  to  which  one  or  more  of  the 
dimensions  of  a  task  changes  over  time.  Dynamicity  is  represented  in  the  diagram  by  the 
shape  of  the  figure  representing  the  activity.  Rectangles  represent  non-dynamic,  or  static 
tasks,  and  ovals  represent  dynamic  tasks. 

9.  Prerequisites  —  Hard  And  Soft 

Prerequisites  are  the  activities  that  are  to  be  performed  prior  to  a  given  activity.  If 
it  is  not  possible  to  perform  the  given  activity  without  the  prerequisite  being  performed 
first,  then  that  prerequisite  is  considered  a  hard  prerequisite.  If  it  is  possible,  but  not 
optimal,  to  perform  the  given  activity  without  the  prerequisite  being  performed  first,  then 
that  prerequisite  is  considered  a  soft  prerequisite.  A  hard  prerequisite  is  represented  in  the 
diagram  by  a  solid  arrow  connecting  two  activities,  while  a  soft  prerequisite  is  denoted  by 
a  dashed  arrow  connecting  two  activities. 

10.  Decomposing  Tasks  Into  Subtasks  And  Actions 

Figure  2  shows  a  task  decomposed  into  subtasks.  Some  of  the  subtasks  shown  are 

in  their  elemental  state  —  they  are  not  further  decomposible.  Most,  though,  can  be 
decomposed  at  least  one  level.  Figure  3  shows  a  subtask  decomposed  into  its  component 
actions. 

The  task  structure  diagram  in  the  elemental  state  follows  the  same  format  as  the 
previously  discussed  task  structure  diagram.  The  only  significant  differences  are  that  the 
task  structure  diagram  in  the  elemental  state  also  contains  the  breakdown  of  the 
dimensions  of  task  structure  that  apply  to  each  action  that  are  not  otherwise  manifested  in 
the  task  structure  diagram  (if  they  are  graded  as  other  than  “Low”  or  “None”),  and  the 
resources  and  information  required  to  complete  the  action. 
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Figure  3.  Subtask  Decomposed  To  Its  Most  Basic  Components 


D.  OPERATIONALIZING  DIMENSIONS  OF  TASK  STRUCTURE  IN  A 
TASK  STRUCTURE  DIAGRAM 

An  important  consideration  for  both  the  task  structure  diagram  just  discussed  and 
the  dimensions  of  task  structure  enumerated  in  the  previous  chapter  is  the  linking  of  the 
two  issues.  How  is  each  dimension  of  task  structure  implemented  in  the  task  structure 
diagram?  Implementation  of  some  dimensions  is  straightforward,  while  others  must  be 
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handled  more  subtly.  This  section  describes  how  each  of  the  nine  dimensions  of  task 
structure  is  manifested  in  the  task  structure  diagram. 

1.  Uncertainty,  Time  Pressure,  Complexity 

Uncertainty,  time  pressure,  and  complexity  are  manifested  in  the  task  structure 
diagram  by  the  level  that  each  is  given  in  the  diagram  that  decomposes  a  task  into  its 
most  elemental  state,  as  shown  in  Figure  3.  The  overall  score  for  a  subtask  in  each  of 
these  dimensions  is  the  mean  of  all  scores  of  the  actions  that  comprise  the  subtask;  the 
overall  score  for  a  task  in  each  dimension  is  the  mean  of  all  scores  of  the  subtasks  that 
comprise  the  task. 

2.  Coordination  Requirements 

Coordination  requirements  are  manifested  in  several  ways  in  the  task  structure 
diagram.  First,  if  the  grade  for  each  type  of  dependency  is  Fligh  or  Medium,  this  will  be 
listed  with  the  action  at  which  it  is  present  on  the  diagram  that  decomposes  the  task  to  its 
most  elemental  state.  In  addition,  the  individual  dependencies  are  represented  separately 
in  the  diagram  as  follows: 

a.  Shared  Resources 

In  Figure  2,  subtasks  that  are  underlined  are  competitive  events.  This  is 
synonymous  with  competition  over  shared  resources.  When  activities  are  imderlined, 
competition  over  shared  resources  is  Medium  or  High. 

b.  Producer/Consumer  Relationships 

The  presence  of  a  hard  prerequisite  indicator  (solid  arrow  coimecting  two 
activities)  in  a  task  structure  diagram  implies  that  a  producer/consumer  dependency 
exists,  since  the  follow-on  activity  cannot  be  performed  until  the  first  is  complete.  When 
the  solid  arrow  is  present,  the  producer/consumer  dependency  is  graded  as  Medium  or 
High. 
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c.  Simultaneity  Constraints 

Simultaneity  is  represented  in  the  task  structure  diagram  by  a  solid  bar 
connecting  the  activities  that  have  the  dependency  relationship.  When  the  solid  bar  is 
present,  simultaneity  constraints  is  graded  as  Medium  or  High. 

d.  Task/Subtask 

While  the  task  structure  diagram  captures  the  breakdown  of  a  task  into  its 
component  subtasks  and  actions,  this  is  not  the  same  as  the  conscious  decomposition  of 
the  task  by  the  actors  into  portions  for  each  to  accomplish  which  the  task/subtask 
dependency  represents.  The  task/subtask  dependency  is  not  manifested  in  the  diagram 
itself,  other  than  the  grade  given  in  the  diagram  that  decomposes  the  task  to  its  most 
elemental  state. 

3.  Magnitude 

The  magnitude  of  a  task  can  be  measured  from  the  task  structure  diagram  by 
breaking  the  entire  task  down  into  its  most  elemental  state  and  generating  one  or  more 
diagrams  similar  to  Figure  3.  Counting  the  total  number  of  actions  in  these  diagrams 
gives  the  task’s  magnitude. 

4.  Resources  And  Information  Required 

Resources  and  information  required  are  given  in  the  diagram  that  decomposes  the 
task  to  its  most  elemental  state.  Counting  the  total  resources  and  pieces  of  information  in 
the  diagram(s)  representing  the  totality  of  actions  within  the  task  gives  the  total  resources 
and  information  required  for  the  task. 

5.  Task  Formalization 

A  task  that  is  amenable  to  description  using  the  task  structure  diagram  will 
probably  have  at  least  a  Medium  level  of  task  formalization.  Indicators  of  formalization 
in  the  diagram  are  the  relative  number  of  soft  and  hard  prerequisites  (more  soft 
prerequisites  would  imply  less  formalization),  and  the  number  of  “or”  operators  (more 
“or”  operators  implies  less  formalization). 
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6.  Dynamicity 

Dynamicity,  as  discussed  earlier,  is  manifested  in  the  task  structure  diagram  by 
the  shape  of  the  node  representing  the  activity. 

E.  TASK  DESIGN  PROCESS 

The  activities  described  in  this  and  the  previous  chapters  can  be  applied  to  the  task 
design  and  scenario  development  problem  stated  in  Chapter  I  in  a  straightforward 
manner.  The  steps  in  the  process  are:  determining  the  dimension  of  task  structure  of 
interest,  determining  the  desired  task  structure,  developing  the  scenario,  and  grading 
scenarios  by  dimensions.  The  second  and  third  steps  can  be  interchanged.  This  process 
will  often  be  iterative,  with  at  least  the  second,  third,  and  fourth  steps  repeated  one  or 
more  times. 


1.  Dimension  of  Interest 

Determining  the  dimension(s)  of  task  structure  of  interest  depends  on  the  goals  of 
the  experiment.  Of  course,  in  order  for  there  to  be  a  task  structure  dimension  of  interest, 
task  structure  must  be  an  independent  variable.  For  example,  if  a  researcher  wanted  to 
determine  whether  larger  or  smaller  tasks  were  performed  better  by  a  certain 
organizational  structure  in  a  specific  environment,  then  his  dimension  of  interest  would 
be  magnitude.  He  should  also  determine  the  number  of  levels  he  will  need  ahead  of  time, 
based  on  the  constraints  of  his  experiment,  and  at  least  an  approximate  figure  for  the 
values  the  levels  will  take  on. 

The  researcher  should  also  determine  the  levels  of  any  of  the  other  dimensions  of 
task  structure  that  he  desires  to  hold  constant,  if  that  is  important  to  his  investigation. 

2.  Desired  Task  Structure 

If  a  certain  structure  within  the  task-subtask-action  decomposition,  or  one  of  the 
characteristics  that  is  best  reflected  in  a  diagram  (such  as  parallelism),  is  desired,  then  a 
preliminary  task  structure  diagram  should  be  developed  after  the  dimension  of  interest 
has  been  determined,  with  detail  filled  in  as  the  scenario  is  written.  If  there  is  no  specific 
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task  structure  requirement  for  the  experiment,  then  the  task  structure  diagram  should  be 
developed  concurrently  with  the  scenario,  to  be  used  as  a  briefing,  explanation,  editing, 
and  grading  tool. 

3.  Scenario  Development 

The  scenario  should  be  developed  based  on  the  above  two  steps,  and  to  fit  within 
the  other  constraints  of  the  experiment,  such  as  project  context,  other  independent 
variables,  subject  pool,  time  and  resources  available,  et  cetera. 

4.  Grading  Dimensions  of  Task  Structure  in  Scenarios 

Finally,  the  scenario(s)  should  be  graded  based  on  the  levels  of  dimensions  of  task 
structure  described  in  Chapter  II,  in  order  to  ascertain  whether  these  dimensions  differ  or 
are  held  constant  as  was  intended. 

F.  SUMMARY 

This  chapter  further  developed  the  concepts  of  the  previous  chapter  by  stipulating 
a  method  by  which  a  task’s  structure  can  be  visually  represented.  This  diagram  not  only 
depicts  the  dimensions  of  task  structure,  but  also  shows  the  flow  of  subtasks  and  actions 
in  the  time  domain,  and  represents  optional  paths,  prerequisites,  and  decomposability. 
The  chapter  began  with  several  definitions  necessary  in  order  to  discuss  task 
decomposition.  Then,  the  task  structure  diagram  and  its  features  were  described,  and  the 
manifestation  of  the  dimensions  of  task  structure  in  the  task  structure  diagram  were  given. 
Finally,  the  work  of  the  last  two  chapters  was  synthesized  and  a  task  design  process  was 
described,  giving  a  straightforward  approach  for  designing  a  military  operational  scenario 
based  on  task  structure. 
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IV.  SCENARIO  DEVELOPMENT  FOR  THE  FIRST  A2C2  EXPERIMENT 

A.  INTRODUCTION 

Chapters  II  and  III  focused  on  enumerating  and  determining  levels  of  dimensions 
of  task  structure,  development  of  a  paradigm  for  visually  representing  task  structure,  and 
stipulation  of  a  process  for  designing  a  task  based  on  the  dimension  of  interest  and 
desired  structure.  This  chapter  returns  to  the  A2C2  context  in  which  this  thesis  is  written. 
Recall  from  Chapter  I  the  original  problems  of  determining  the  dimension  of  task 
structure  to  be  varied,  the  structural  form  the  task  will  take,  and  development  of  a 
scenario  and  variants  to  fit  within  those  constraints  for  the  initial  experiment  within  the 
A2C2  project.  These  issues  will  be  dealt  with  in  this  chapter,  using  the  tools  developed  in 
Chapters  II  and  III.  I  will  also  describe  the  conduct  of  that  initial  experiment,  and 
operationalization  of  the  task  and  organization  structures. 

B.  DETERMINATION  OF  THE  DIMENSION  OF  INTEREST 

1.  Background 

It  was  stated  in  Chapter  I  that  the  specific  dimension  of  interest  for  the  first 
experiment  with  regard  to  organizational  structure  was  levels  of  hierarchy,  and  whether 
there  are  circumstances  in  which  a  flattened  organizational  structure  would  tend  to 
outperform  a  more  hierarchical  structure,  and  vice  versa.  An  issue  that  arose  several  times 
during  the  A2C2  field  research  concerned  these  circumstances.  The  organizational 
structure  used  in  the  joint  officer  interviews  was  relatively  “flat,”  and  several  of  the 
officers  saw  reasons  to  add  a  layer  of  hierarchy,  typically  when  one  force  might  need 
assets  that  belonged  to  another  (a  shared  resources  dependency  under  the  dimension  of 
coordination  requirements,  from  Chapter  II).  The  extra  layer  of  hierarchy  would 
presumably  facilitate  coordination  when  two  units  were  competing  over  one  another’s 
assets.  The  same  question  came  up  in  field  visits  to  warfighting  commands. 
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2. 


Research  Issue  and  Hypotheses 


Based  on  the  field  research  and  my  work  in  defining  dimensions  of  task  structure 
in  Chapter  II,  the  A2C2  team  formulated  a  general  research  issue:  can  tasks  differ  in 
coordination  requirements  in  such  a  way  that  an  organization  structure  with  more  layers 
is  better  for  some  tasks,  and  a  structure  with  fewer  layers  is  better  for  others?  From  that 
research  issue,  our  general  hypothesis  developed:  there  is  an  interaction  between  task 
structure  and  organization  structure,  when  coordination  requirements  and  levels  of 
hierarchy  are  the  respective  dimensions  of  interest.  More  specifically,  when  two  units  in 
the  same  functional  area  must  coordinate  the  use  of  assets  in  order  to  process  their 
individual  tasks: 

•  An  organization  with  a  common  functional  commander  is  better  when  the 
assets  are  owned  by  one  of  the  two  units,  whereas 

•  An  organization  without  a  common  functional  commander  is  better  when  the 
assets  are  owned  outside  of  the  functional  area. 

The  reasoning  behind  the  first  assertion  is  that  placing  an  experienced  component 
commander  over  all  forces  in  a  functional  area  will  focus  those  forces  on  a  common 
mission  or  goal.  The  subordinate  commanders  will  be  more  likely  to  make  decisions  that 
are  optimal  for  the  component  as  a  whole,  and  if  they  do  not,  the  common  commander, 
with  his  component-centric  focus,  will  be  able  to  mitigate  conflicts  within  the  component 
in  a  timely  manner.  The  overall  commander,  on  the  other  hand,  is  poorly  positioned  to  act 
as  the  common  commander.  He  focuses  at  a  higher  level,  considering  the  air,  ground,  and 
naval  context  as  a  whole.  He  is  too  busy  with  command  and  control  of  the  overall 
operation  to  narrow  his  focus  and  mitigate  conflicts  within  a  component  in  a  timely 
manner. 

On  the  other  hand,  when  a  lower  level  commander  in  one  functional  area  needs  an 
asset  that  belongs  to  the  overall  commander  (or  his  superiors),  and  that  asset  might  also 
be  needed  by  a  unit  in  another  functional  area,  the  overall  commander  must  become 
cognizant  of  the  specific  needs  within  the  functional  area  before  he  allocates  the  asset.  If 
the  overall  commander  and  the  lower  level  units  all  share  a  common  operational  picture, 
the  overall  commander  will  not,  in  theory,  need  component  commanders  to  apprise  him 
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of  the  seriousness  of  their  respective  units’  needs  before  he  makes  his  decision.  If  lower 
level  commanders  have  a  common  operational  picture,  they  presumably  should  be  able  to 
act  in  a  more  autonomous  manner  to  achieve  the  commander’s  intent  and  allocate 
resources  among  themselves.  As  a  result,  the  overall  commander  should  be  able  to 
increase  his  span  of  control  and  the  organization  can  become  “flatter.” 

3.  Dimension  of  Interest 

Based  on  the  above  research  issue  and  hypotheses,  the  task  structure  dimension  of 
interest  was  the  “competition  over  shared  resources”  subcategory  of  coordination 
requirements.  It  was  presented  at  two  levels,  level  one  is  high  internal  competition  over 
shared  resources  (competition  over  organic  assets),  level  two  is  high  external  competition 
over  shared  resources  (competition  over  non-organic  assets).  It  was  desired  that  all  other 
dimensions  of  task  structure  remain  constant.  The  factors  for  the  final  2x2  experimental 
design,  then,  became  organization  structure  (two-tiered  hierarchy  versus  three-tiered 
hierarchy)  and  task  structure  (competition  over  organic  assets  versus  competition  over 
non-organic  assets). 

C.  DESIRED  TASK  STRUCTURE 

The  A2C2  team  also  had  specific  ideas  about  the  structural  characteristics  of  the 
desired  task,  and  levels  of  other  dimensions  that  would  allow  for  optimum  accessibility  to 
the  task  and  organization  structure  dimensions  of  interest. 

1.  Formalization 

A  high  degree  of  formalization  was  considered  desirable.  The  researchers  wanted 
there  to  be  a  consistent  structural  form  to  the  task,  and  replicable  events  which  would 
occur  in  each  task  requiring  each  team  of  subjects  to  compete  over  the  same  resources  in 
identical  circumstances.  Crucial  to  this  requirement  was  the  need  for  “one-of-a-kind” 
resources.  Normally,  any  military  force  has  a  certain  amount  of  robustness  built  in  — 
there  is  generally  more  than  one  asset  that  can  perform  a  given  mission.  For  example,  in 
an  aircraft  carrier  battle  group,  there  are  any  number  of  weapons,  from  aircraft  to  frigates 
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to  destroyers,  which  can  engage  fast  patrol  boats.  However,  if  that  multiplicity  of  assets 
had  been  allowed  in  this  experiment,  then  each  team  of  subjects  would  have,  in  effect, 
created  its  own  task  structure,  potentially  completing  tasks  while  avoiding  the 
competition  that  was  the  point  of  the  experiment. 

2.  Prerequisites 

In  spite  of  the  desire  for  high  formalization,  the  experimental  designers  wanted 
the  subjects  to  be  free  to  make  some  errors,  particularly  involving  the  competition  events 
—  the  subjects  needed  to  be  able  to  make  the  wrong  decision.  As  such,  prerequisites 
leading  up  to  the  competition  events  tended  to  be  hard,  and  prerequisites  within  the 
competition  events  themselves  tended  to  be  soft.  In  execution,  though,  there  were 
exceptions  to  this  rule,  which  occasionally  resulted  in  the  desired  competition  events  not 
occurring,  or  occurring  in  ways  that  the  experimental  designers  had  not  anticipated. 

3.  Separability  of  Maritime  and  Ground  Portions 

The  experimental  designers  envisioned  a  scenario  involving  a  joint  task  force 
(JTF)  with  two  components  under  the  JTF,  a  maritime  component  and  a  ground 
component,  each  component  further  comprised  of  two  lower-level  units.  Recall  from 
Chapter  1  that  the  two  levels  of  organizational  structure  to  be  tested  in  this  experiment 
were  two-tiered  and  three-tiered.  Although  the  two-tiered  and  three-tiered  structures  were 
separated  for  analysis,  the  two  JTF  organizations  that  were  used  for  the  experiment  each 
had  an  intermediate  commander  supervising  one  component  and  none  supervising  the 
other.  Thus,  in  half  of  the  runs  there  was  a  ground  component  commander  (GCC),  while 
in  the  other  half  there  was  a  maritime  component  commander  (MCC),  as  shown  in  Figure 

4.  This  was  done  in  order  to  keep  the  number  of  subjects  constant  across  all  trials,  and 
avoid  task-load-per-individual  problems  that  would  have  arisen  had  the  two  structures 
been  composed  of  different  numbers  of  subjects. 
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Figure  4.  Organizational  Structures  Used  In  Experiment 


A  goal  of  the  design  team  was  for  the  competition  events  in  the  scenario  to  be 
modular  with  regard  to  the  components;  competition  events  should  not  occur  across 
components,  but  between  the  two  lower  level  units  within  each  component.  A  module 
was  then  defined  as  that  portion  of  a  scenario  that  affected  one  component.  A  desired 
result  of  this  separation  of  ground  and  maritime  competition  events  was  a  potential 
doubling  of  the  number  of  data  points,  since  two  sets  of  competition  scores  per 
experimental  run  would  then  be  received.  A  complete  scenario  was  composed  of  two 
modules  —  one  maritime  and  one  ground.  The  modules  were  numbered  as  follows: 

•  Module  1 :  Competition  Between  Ground  Units  for  Organic  Assets 

•  Module  2:  Competition  Between  Ground  Units  for  Non-Organic  Assets 

•  Modules:  Competition  Between  Maritime  Units  for  Organic  Assets 

•  Module  4:  Competition  Between  Maritime  Units  for  Non-Organic  Assets 

Modules  1  and  3  were  combined  to  form  Scenario  13,  competition  for  organic 

assets  (level  one),  and  Modules  2  and  4  were  combined  to  form  Scenario  24,  competition 
for  non-organic  assets  (level  two). 

The  designers  further  wanted  the  task  structure  of  the  ground  and  maritime 
modules  to  be  as  similar  as  possible,  within  levels;  the  Module  1  task  structure  diagram 
should  look  like  the  Module  3  diagram,  and  Module  2  should  likewise  resemble  Module 
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4.  This  proved  to  be  difficult,  because  of  the  basic  difference  in  the  ground  and  maritime 
missions  that  will  be  discussed  in  a  later  chapter. 


D.  SCENARIO  DEVELOPMENT 

The  scenario  for  the  first  experiment  was  adapted  from  the  scenario  used  for  the 
joint  officer  interviews  (Alphatech,  Inc.,  1995) .  My  goal  was  to  design  two  variants  of 
the  same  scenario,  one  to  be  used  as  level  one  (Scenario  13)  and  the  other  as  level  two 
(Scenario  24),  identical  except  for  the  competition  events. 

What  follows  is  a  detailed  description  of  the  scenarios  I  developed,  including  the 
general  situation,  enemy  situation,  firiendly  forces  and  asset  ownership,  mission,  how  the 
mission  will  be  executed  by  fnendly  forces,  fi-iendly  force  priorities,  the  manner  in  which 
each  variation  of  the  scenario  should  unfold,  and  the  scenarios  used  for  training  the 
subjects. 

1.  General 

Orange,  a  North  Afncan  nation  friendly  to  the  United  States,  is  under  attack  by 
Green,  whose  forces  have  taken  control  of  Orange’s  port  of  Eastport.  A  Joint  Task  Force 
(JTF)  is  organized  by  a  notional  theater  commander  in  chief,  the  Commander  in  Chief, 
Mediterranean  Command  (CINCMED),  in  order  to  capture  the  port  and  airfield  of 
Eastport  to  allow  for  the  introduction  of  follow-on  forces.  CINCMED’s  ultimate  purpose 
will  be  to  drive  Green  forces  from  Orange  and  destroy  their  capability  for  offensive 
warfare.  The  Commander,  JTF  (CJTF)  has  at  his  disposal  an  aircraft  carrier  battle  group 
(CVBG),  an  amphibious  ready  group  (ARG)  large  enough  to  transport  two  Marine 
Expeditionary  Units  (Special  Operations  Capable)  (MEU(SOC)),  and  two  separate  MEU 
(SOC)s.  Figure  5  gives  a  representation  of  the  Eastport  area. 
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2.  Enemy  Situation 

A  helibome  or  across  the  beach  assault  directly  into  the  port  of  Eastport  would  be 
too  risky  beeause  of  obstructions,  mines,  obstaeles,  and  the  presence  of  hidden  enemy 
among  the  port  facility  buildings  armed  with  handheld  surface-to-air  missiles.  About  5 
miles  south  of  the  port,  there  are  two  suitable  landing  beaehes.  There  is  a  road  leading 
from  the  northernmost  beach  (designated  “Red  Beach”)  to  the  port,  and  another  leading 
from  the  southernmost  beach  (designated  “Blue  Beach”)  to  the  airfield.  The  waterborne 
approaches  to  the  beaehes  are  possibly  mined,  and  a  piece  of  commanding  terrain  to  the 
north  of  Red  Beach  is  occupied  by  an  enemy  heavy  mortar  platoon  with  a  platoon  of 
infantry  for  security.  This  commanding  terrain  dominates  both  Red  Beach  and  the  port, 
and  must  be  taken  and  held  throughout  any  attack  on  Red  Beach  or  the  port. 

Known  to  be  at  the  port,  but  hidden  from  view,  is  a  company-sized  mechanized 
counterattack  force  that  could  move  toward  Red  Beach  to  try  to  foil  any  amphibious 
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assault.  It  is  possible  that  there  is  a  similar  counterattack  force  at  the  airfield,  which  is 
located  about  5  miles  inland  from  Blue  Beach.  The  counterattacking  forces  could  inflict 
serious  damage  if  they  are  not  interdicted  before  they  arrive  at  either  beach  once  they 
begin  movement.  The  off-road  terrain  between  the  beaches,  port,  airfield,  and 
commanding  terrain  is  swampy  and  treacherous,  and  is  unsuitable  for  travel.  Thus,  all 
travel  must  be  on  the  two  roads.  It  is  suspected  that  one  or  both  of  the  roads  will  be 
mined,  but  the  locations  of  any  minefields  are  unknown,  and  will  not  be  known  until 
friendly  units  approach  them.  These  “pop-up”  minefields  must  be  breached  by  engineers 
before  the  friendly  forces  can  move  beyond  them. 

The  port,  airfield,  both  roads,  both  beaches,  and  the  commanding  terrain  are 
located  within  range  of  two  artillery  strongpoints,  one  about  10  miles  northwest  of  the 
port,  and  the  other  about  10  miles  south  of  the  airfield.  The  northernmost  strongpoint  can 
range  Red  Beach  and  the  port,  and  the  southernmost  strongpoint  can  range  the  airfield 
and  Blue  Beach.  Both  are  within  range  of  two  Naval  Surface  Fire  Support  (NSFS) 
stations  off  the  port  —  one  in  support  of  MEU  1,  and  the  other  in  support  of  MEU  2.  The 
artillery  pieces  at  both  strongpoints  are  housed  in  reinforced  concrete  bunkers,  and  the 
ammunition  stored  in  deep  underground  bunkers,  so  it  is  unlikely  that  even  concentrated 
air  attacks  by  the  assets  under  the  JTF’s  control  will  completely  disable  the  artillery 
strongpoint.  When  the  enemy  wants  to  fire  an  artillery  barrage,  they  wheel  out  the 
artillery  pieces,  set  them  up,  and  fire  within  15  minutes.  If  friendly  forces  can  get 
effective  NSFS  on  target  in  less  than  1 5  minutes,  the  enemy  will  wheel  their  artillery 
pieces  back  into  their  bunkers  and  wait  until  another  time. 

The  enemy  also  has  several  FROG  surface-to-surface  missile  launchers,  known  to 
be  capable  of  carrying  chemical  munitions,  hidden  in  the  vicinity  of  both  artillery 
strongpoints.  They  can  emerge  from  their  covered  positions,  prepare  their  warheads,  and 
fire  their  missiles  within  30  minutes.  Past  experience  has  shovm  that  the  FROG  crews  are 
more  stalwart  than  their  artillery  comrades  —  they  will  continue  to  prepare  and  launch 
their  missiles  even  if  they  are  being  suppressed  by  NSFS.  Close  air  support  (CAS) 
aircraft  with  precision  guided  munitions  are  the  only  weapons  in  the  JTF’s  possession 
that  are  highly  effective  against  this  target,  if  the  aircraft  can  arrive  in  time. 
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At  sea,  the  enemy  submarine  threat  is  considerable.  The  Green  forces  have  one 
Alfa-class  submarine  known  to  be  in  the  area,  and  one  more  possible.  They  possess 
MI-24  Hind  helicopters  and  strike  aircraft  as  well,  both  of  which  have  demonstrated  the 
capability  to  launch  anti-ship  missiles. 

The  only  surface  threat  that  friendly  naval  forces  face  is  that  posed  by  the  Green 
navy,  which  possesses  numerous  fast  patrol  boats.  These  fast  patrol  boats  can  either  fire 
very  potent  Russian  torpedoes  or  be  loaded  with  explosives  for  suicide  missions. 

Finally,  there  are  two  suspected  Silkworm  anti-ship  missile  launchers:  one  in  the 
city  of  Eastport  itself  and  the  other  in  a  southern  residential  district.  These  Silkworm 
launchers  were  placed  in  residential  neighborhoods  by  the  Green  forces  because  they 
knew  U.S.  planners  would  be  reluctant  to  target  these  areas.  Accordingly,  if  the  CVBG  or 
ARG  wish  to  target  a  Silkworm  launcher,  they  must  first  get  visual  confirmation  of  its 
presence,  using  theater  SR-71  assets,  and  any  strike  must  use  CAS  with  precision  guided 
munitions  in  order  to  minimize  collateral  damage. 

3.  Friendly  Situation  and  Asset  Ownership 

The  JTF  exists  within  the  structure  of  the  Mediterranean  Command  (MEDCOM). 
There  is  a  theater-level  Joint  Force  Air  Component  Commander  (JFACC)  and  other 
fiiendly  forces  operating  against  the  enemy  in  Orange,  but  not  in  concert  with  the  JTF. 
The  only  aircraft  from  the  CVBG  available  to  support  the  JTF  are  one  section  of  FA- 18s 
with  laser  guided  bombs  to  attack  FROG  launchers,  another  designated  to  attack 
confirmed  Silkworm  missile  sites,  and  enough  combat  air  patrol  (CAP)  aircraft,  used  for 
anti-air  warfare,  to  man  two  CAP  stations,  one  above  the  CVBG  and  the  other  above  the 
ARG.  All  other  CVBG  assets  will  support  the  theater  JFACC,  and  will  be  unavailable  for 
JTF  use.  The  CVBG  will  control  an  aircraft  carrier,  an  AEGIS  cruiser  which  is  only 
capable  of  performing  anti-air  warfare  (AAW)  functions,  and  a  frigate  which  can  only  be 
used  for  antisubmarine  warfare  (ASW).  The  ARG  will  control  two  destroyers  in  position 
to  provide  NSFS  against  either  artillery  strongpoint  (incapable  of  performing  ASW  or 
AAW),  several  amphibious  ships  with  the  MEUs  embarked,  and  one  Stinger  platoon 
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detached  from  one  of  the  MEUs  capable  of  providing  close  in  air  defense  against 
helicopters  (the  only  asset  in  the  JTF  so  capable). 

MEU  1  is  composed  of  one  Advanced  Amphibious  Assault  Vehicle  (AAAV) 
mounted  infantry  company,  one  V-22  Osprey  mounted  helibome  infantry  company,  one 
division  (4)  of  AH-IW  Cobra  attack  helicopters  (indivisible),  and  one  V-22  mounted 
engineer  platoon.  MEU  2  is  composed  of  one  AAAV  mounted  infantry  company,  one 
V-22  mounted  helibome  infantry  company,  and  2  MEDEVAC  helicopters  (also 
indivisible).  MEU  1  has  the  Cobras  and  Engineers  because  it  is  considered  probable  that 
the  port  will  be  more  heavily  defended  by  mechanized  assets  and  minefields  than  the 
airfield.  Each  MEU  will  be  considered  to  have  a  unmanned  aerial  vehicle  (UAV)  flying  in 
its  support  for  the  duration  of  the  operation.  The  players  will  not  control  the  UAVs  but 
their  presence  will  be  represented  by  the  nearly  omniscient  battlefield  picture  each  MEU 
will  possess. 

The  CJTF  controls  the  two  sections  of  CAS  aircraft  previously  mentioned,  one 
mine  countermeasures  (MCM)  helicopter  embarked  aboard  the  ARG  which  can  clear 
mines  if  they  are  detected,  a  section  of  SH-60s  armed  with  Penguin  missiles  aboard  the 
carrier  to  be  used  against  any  small  patrol  boats  that  threaten  JTF  forces  (anti-surface 
warfare  (ASUW)),  and  a  V-22  mounted  helibome  infantry  company  aboard  the  ARG. 
This  helibome  infantry  company  is  the  JTF  reserve.  In  addition,  there  is  a  possibility  of 
obtaining  JFACC  air  defense  assets  from  Sicily  at  the  CJTF’s  request  in  the  event  that  the 
carrier-based  fighters  become  unavailable,  and  a  SR-71  is  constantly  in  orbit,  in  general 
support  of  the  theater  commander-in-chief,  that  can  be  requested  by  the  CJTF  for  any 
immediate  imagery  requirements. 

As  mentioned  previously,  the  assets  were  designed  unrealistically  as 
one-of-a-kind  assets,  in  which  only  a  single  asset  can  accomplish  a  task  in  any  given 
situation,  in  order  to  induce  competition  where  the  experimental  designers  wanted  it  to 
occur.  Additionally,  the  “non-organic”  assets  were  placed  under  the  CJTF  rather  than  the 
MCC  or  GCC,  although  it  would  have  been  more  realistic,  in  some  circumstances,  to 
place  the  assets  at  the  intermediate  level  of  hierarchy  when  present.  This  was  done  for 
consistency;  the  experimental  designers  wanted  to  hold  the  resource  stmcture  constant.  A 
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summary  of  the  assets  available,  owners,  and  the  threats  that  can  be  destroyed  or  tasks 
handled  by  each  asset  is  as  shown  in  Table  3. 


Asset 

Owner 

Task(s)  Asset  Can  Accomplish 

Helibome  Infantry  Company 

MEUl 

Attack  Enemy  Positions  &  Ground 

MEU2 

CJTF 

Forces,  Hold  Positions 

AAAV-Mounted  Infantry  Company 

MEU  1 

Attack  Enemy  Positions  &  Ground 

MEU2 

Forces,  Hold  Positions 

Engineer  Platoon 

MEU  1 

Clear  Mines  on  Land 

AH-1 W  Cobra  Helicopters 

MEUl 

Enemy  Tanks 

MEDEVAC  Helicopters 

MEU  2 

Perform  Medical  Evacuation 

Frigate 

CVBG 

Perform  ASW 

AEGIS  Cruiser 

CVBG 

Perform  AAW 

F-14  CAP 

CVBG 

ARG 

Perform  AAW 

Destroyer 

ARG 

Provide  NSFS  Against  Artillery 

Stinger  Platoon 

ARG 

Perform  AAW  Against  Helicopters 

SH-60  Helicopters 

CJTF 

Perform  ASUW 

CAS  Aircraft 

CJTF 

Destroy  FROG  &  Silkworm  Launchers 

F-15  CAP 

CJTF 

Perform  AAW 

SR-71 

CJTF 

Identify  Silkworm  Launchers 

MCM  Helicopters 

CJTF 

Clear  Mines  fi-om  Beach 

Table  3.  Assets,  Ownership,  and  Capabilities 


The  DDD-III  implemented  the  asset-to-task  matchings  via  specification  of  task 
resource  requirements  and  asset  resource  capability.  To  each  task  (and  asset)  there  was 
associated  a  7-dimension  resource  vector  R  =  [rl,  r2,  ...  ,  r7]  with  components  that 
correspond  to  combat  capability/potential,  or  task  requirements  in  various  categories.  For 
example,  rl  —  air  combat,  r2  —  sea  combat, ...,  r5  =  mines,  r6  =  holding/occupying,  r7  = 
medivac.  By  giving  a  specific  task  a  set  of  values  for  R  the  DDD-III  establishes  what 
(mix  of)  assets  with  their  corresponding  Rs  suffice  to  correctly  process  that  task.  Thus, 
mine-clearing  helicopters  would  have  values  for  r5  corresponding  to  those  required  for 
mine  clearing  tasks,  but  other  assets  would  have  lower  values  for  r5,  or  zero  (Kemple,  et 
al.,  1996a). 
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4. 


Mission 


Ground  Component:  To  secure  the  port  and  airfield  of  Eastport,  to  allow  for  the 
introduction  of  follow-on  forces. 

Maritime  Component:  To  support  the  amphibious  operation  with  close  air 
support,  naval  surface  fire  support,  mine  countermeasures,  and  air  defense  assets,  and  to 
defend  the  CVBG  and  ARG  from  air,  surface,  and  subsurface  threats. 

5.  Execution 

Each  MEU  will  simultaneously  land  its  AAAV-mounted  company  on  the  beach. 
MEU  1  will  attack  Red  Beach,  and  MEU  2  will  attack  Blue  Beach.  MEU  1  will 
simultaneously  secure  the  commanding  terrain  overlooking  Red  Beach  and  the  port  with 
its  helibome  company.  Once  the  beaches  and  commanding  terrain  are  secure,  the  two 
AAAV-mounted  companies  will  proceed  down  the  roads  from  their  respective  beaches, 
clearing  minefields  with  the  engineer  platoon,  killing  counterattack  forces  with  the 
Cobras,  and  conducting  MEDEVACs  as  necessary. 

Each  MEU  will  have  a  UAV  (launched  from  the  ARG)  airborne  for  the  duration 
of  the  operation.  The  UAVs  will  keep  the  artillery  strongpoints  and  the  suspected  FROG 
sites  under  constant  surveillance,  so  that  NSFS  or  CAS  assets  can  be  brought  to  bear 
immediately  if  they  are  needed.  The  section  of  CAS  aircraft  earmarked  for  use  against 
FROG  launchers  will  be  on  5  minute  strip  alert  aboard  the  aircraft  carrier. 

Once  the  roads  have  been  cleared,  the  AAAV-mounted  companies  from  MEU  1 
and  MEU  2  will  attack  the  port  and  the  airfield,  respectively.  MEU  2’s  AAAV-mounted 
company  will  be  joined  in  its  attack  by  a  helibome  company  from  MEU  2.  It  is  important 
that,  once  the  AAAV-mounted  companies  land  on  the  beach,  the  airfield  and  port  be 
taken  as  quickly  as  possible,  before  the  enemy  has  a  chance  to  organize  his  defense  and 
send  reinforcements.  It  is  desired  that  final  assaults  on  the  airfield  and  port  be  conducted 
simultaneously,  in  order  to  present  the  enemy  commander  with  the  most  confusing, 
dilemma-filled  environment  possible,  but,  if  one  attack  must  be  conducted  before  the 
other,  the  airfield  takes  priority.  If  the  airfield  attack  is  held  up  for  any  reason,  the  port 
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attack  should  wait  to  retain  the  synergism  of  concurrent  attacks;  if  the  port  attack  is  held 
up,  the  airfield  attack  should  go  forward.  The  CJTF’s  reserve  infantry  company  can  be 
requested  by  whichever  MEU  needs  it  at  any  point  during  the  operation,  in  case  either  the 
port  or  the  airfield  are  too  well  defended  for  MEU  1  or  MEU  2  to  be  able  to  secure  them 
with  the  forces  available. 

Due  to  hydrographic  limitations,  the  ARG  and  the  CVBG  will  have  to  be 
significantly  separated  during  the  operation,  enough  to  preclude  them  fi'om  being  under  a 
joint  air  defense  umbrella  provided  by  the  AEGIS  cruiser.  Thus,  the  AEGIS  cruiser  will 
remain  with  the  CVBG,  but  will  position  itself  so  that  it  can  rapidly  move  fi'om  the 
CVBG  to  the  ARG  if  that  becomes  necessary.  Additionally,  the  two  destroyers  will  be 
inshore,  providing  NSFS  support,  while  the  frigate  is  the  primary  anti-submarine  warfare 
platform  for  the  CVBG.  The  frigate  performing  anti-submarine  warfare  will,  like  the 
AEGIS  cruiser,  position  itself  so  that  it  can  quickly  move  to  support  the  ARG  if  that  is 
necessary.  Any  assets  supporting  the  ARG  must  be  under  the  control  of  the  ARG,  and 
assets  supporting  the  CVBG  must  be  under  the  control  of  the  CVBG. 

The  ARG  will  launch  the  aforementioned  three  companies  of  Marines  for  the 
initial  assault  on  Red  and  Blue  Beaches.  The  ARG  will  launch  the  mine  countermeasures 
helicopters.  Cobras,  MEDEVAC  aircraft,  the  air  assault  for  MEU  2’s  attack  on  the 
airfield,  and  the  CJTF  reserve  when  called  to  do  so.  The  ARG  will  also,  with  its 
destroyers  providing  NSFS,  suppress  the  artillery  strongpoints  ashore  when  requested  to 
do  so  by  either  of  the  MEUs. 

The  CVBG  will  keep  two  sections  of  FA- 18s  with  precision  guided  munitions  on 
standby  at  all  times:  one  to  be  used  against  FROGs  (in  support  of  the  MEUs),  and  the 
other  against  Silkworms  (in  support  of  the  CVBG  or  ARG).  The  CJTF  will  be  launch 
authority  for  both  sections.  The  CVBG  will  also  provide  2  sections  per  hour  of  air 
defense  aircraft  (FA-18  or  F-14),  with  one  CAP  station  over  the  CVBG  and  the  other  over 
the  ARG. 

If  the  CVBG  or  ARG  encounters  a  surface  threat,  then  it  must  request  the  SH-60s 
from  the  CJTF  in  order  to  deal  with  that  threat.  If  a  suspected  Silkworm  launcher  is 
detected,  then  it  must  be  identified  first  by  the  SR-71  before  it  can  be  destroyed.  A 
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Silkworm  launcher  detected  at  the  northernmost  site  threatens  the  CVBG;  at  the 
southernmost  site,  the  ARG. 

6.  Priorities 

The  JTF’s  overall  priority,  and  the  priority  within  the  ground  component,  is  MEU 
2’s  attack  on  the  airfield,  because  buildup  of  friendly  forces  can  be  most  quickly  and 
effectively  achieved  through  air  transport. 

The  following  was  given  to  the  subjects  as  the  CJTF’s  priorities  within  the 
maritime  component:  if  both  the  ARG  and  CVBG  are  threatened  by  the  enemy,  the  ARG 
has  priority  of  support  against  submarine  threats,  fixed-wing  air  threats,  and  patrol  boats. 
If  there  is  a  threat  of  an  air  attack  against  the  ARG,  the  ARG  should  get  the  AEGIS 
cruiser  and  a  CAP.  The  frigate  performing  anti-submarine  warfare  and  the  AEGIS  cruiser 
stay  with  the  CVBG  unless  a  necessity  occurs  with  the  ARG,  however,  because  the 
CVBG  is  considered  a  more  likely  target  for  the  enemy.  The  CVBG  has  priority  against 
land-based  Silkworm  sites  and  helicopters.  The  Stinger  platoon  will  remain  on  the  ARG, 
however,  because  it  is  considered  a  more  likely  target  for  enemy  helicopters,  since  the 
only  known  enemy  helicopter  bases  are  closest  to  the  ARG,  and  will  only  transfer  to  the 
CVBG  if  there  is  evidence  of  an  imminent  attack.  To  expedite  this  transfer,  should  it 
become  necessary,  the  Stinger  platoon  will  have  V-22  helicopters  at  its  disposal. 

7.  Scenario  13,  Competition  Over  Organic  Assets 

In  Scenario  13,  the  ground  component  (MEU  1  and  MEU  2)  competed  for  MEU 
Us  engineer  platoon  and  Cobras  and  MEU  2’s  MEDEVAC  helicopters.  The  maritime 
component  (ARG  and  CVBG)  competed  over  the  ARG’s  Stinger  platoon  and  the 
CVBG’s  AEGIS  cruiser,  frigate,  and  section  of  CAP  aircraft.  Non-organic  assets  that 
were  not  competed  over,  but  were  used,  were  the  reserve  helibome  company,  mine 
countermeasures  helicopter,  JFACC  CAP  aircraft,  the  SH-60s,  the  SR-71  mission,  and 
the  CAS  aircraft  to  be  used  against  Silkworms  and  FROGs.  These  non-organic  assets 
were  competed  over  in  Scenario  24. 
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On  the  ground  side,  the  scenario  started  with  MEU  2  detecting  mines  as  it 
approached  the  beach.  MEU  2  should  have  immediately  requested  the  mine 
countermeasures  helicopter  to  clear  the  mines.  Once  the  mines  were  clear,  the  air  assault 
on  commanding  terrain  and  the  AAAV  assaults  on  Red  and  Blue  Beaches  then  occurred 
conciurently .  After  the  AAAV-mounted  companies  had  taken  the  beaches  and  began 
moving  down  their  respective  roads,  enemy  tanks  were  observed  moving  down  both 
roads  towards  Red  and  Blue  Beaches.  MEU  1  and  MEU  2  competed  for  the  Cobras  — 
since  MEU  2  had  priority,  the  correct  response  would  be  for  MEU  2  to  use  them  first. 
Parallel  with  the  assault,  the  enemy  artillery  from  the  northern  strongpoint  was  observed 
coming  out  of  its  bunkers  by  MEU  1,  which  should  have  called  NSFS  to  suppress  it.  The 
artillery  would  emerge  from  its  strongpoints  about  every  five  minutes  throughout  the 
scenario  to  threaten  alternately  MEU  1  and  MEU  2.  This  was  not  used  as  a  competition 
event,  but  as  “busywOrk”  to  ensure  the  players  had  enough  to  do. 

Soon  after  the  tanks  appeared,  friendly  casualties  were  incurred  at  both  beaches. 
MEU  I’s  casualties  were  most  severe,  so  the  correct  response  was  for  MEU  2  to  give 
their  MEDEVAC  helicopters  to  MEU  1. 

After  the  enemy  tanks  were  dealt  with,  MEU  1  and  MEU  2  could  begin  moving 
down  their  respective  roads  toward  their  objectives.  They  then  simultaneously 
encountered  minefields  on  the  roads  —  MEU  2  had  priority,  so  the  correct  response  was 
for  MEU  1  to  give  its  engineer  platoon  to  MEU  2.  At  about  the  same  time  as  MEU  1  was 
clearing  its  mines,  a  FROG  launcher  emerged  from  hiding,  observed  by  MEU  2’s  UAV. 
MEU  2  should  then  have  requested  the  standby  CAS  section  to  attack  the  FROG 
launcher.  MEU  2,  meanwhile,  should  have  begun  conducting  its  coordinated  attack  on  the 
airfield. 

After  MEU  1  finished  clearing  its  mines,  it  should  have  attacked  the  port.  As  it 
approached  the  port,  the  MEU  1  commander  realized  that  the  enemy’s  strength  at  the  port 
was  greater  than  he  expected.  Fie  needed  to  call  for  the  reserve  company  before  he  could 
attack.  Upon  completion  of  MEU  I’s  attack,  the  ground  objective  was  achieved.  A  task 
structure  diagram  depicting  Module  1  is  given  in  Figure  6. 
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On  the  maritime  side,  shortly  after  the  detection  of  the  mines  in  front  of  Blue 
Beach,  submarines  were  detected,  one  moving  toward  the  ARG  and  the  other  toward  the 
CVBG.  The  correct  response  was  for  the  CVBG  to  give  its  frigate  to  the  ARG.  At  the 
same  time,  two  sections  of  CAP  aircraft  launched  from  the  carrier,  one  for  the  CAP 
station  above  the  CVBG,  and  the  other  for  the  CAP  station  over  the  ARG.  They  remained 
on  station  for  one  hour. 
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Soon  afterward,  and  after  the  MEUs’  assault  on  Red  and  Blue  Beaches,  Green 
Hind  helicopters  with  antiship  missiles  were  detected  preparing  to  take  off  from  two 
airfields,  one  within  range  of  the  CVBG  and  the  other  within  range  of  the  ARG.  The 
correct  response  was  for  the  ARG  to  transfer  its  Stinger  platoon  to  the  CVBG,  since  the 
CVBG  had  priority.  After  this,  and  concurrently  with  the  clearing  of  the  minefields  in  the 
roads  ashore,  two  things  happened.  First,  fast  patrol  boats  were  detected  approaching  the 
CVBG.  The  CVBG  should  have  requested  the  SH-60s  firom  the  CJTF  to  destroy  this 
threat.  Also,  an  intelligence  report  of  a  fixed-wing  air  attack  preparing  to  take  off  against 
the  ARG  was  received  from  the  theater  commander-in-chief.  The  correct  response  was 
for  the  CVBG  to  transfer  the  AEGIS  cruiser  to  the  ARG.  Also  at  the  same  time,  both 
CAP  aircraft  ran  out  of  fuel,  and  returned  to  the  carrier.  Only  one  relief  section  was 
available  —  belonging  to  the  CVBG.  This  should  also  have  been  diverted  to  the  ARG, 
because  the  ARG  had  priority.  Soon  afterward,  if  requested,  a  section  of  JFACC  F-15s 
from  Sicily  came  out  to  support  the  CVBG. 

Next,  a  report  was  received  of  a  Silkworm  site  in  the  north,  threatening  the 
CVBG.  The  CVBG  requested  SR-71  overflight  to  confirm  the  missile  site,  then  requested 
launch  of  the  FA- 18s  with  precision  guided  munitions  to  destroy  it.  Figure  7  is  a  task 
structure  diagram  depicting  the  Module  3  task. 

8.  Scenario  24,  Competition  Over  Non-Organic  Assets 

In  this  scenario,  the  organic  and  non-organic  assets  were  the  same  as  in  Scenario 
13;  however,  the  organic  assets  were  not  competed  over,  and  the  non-organic  assets  were. 
Scenario  24  unfolded  as  did  Scenario  13,  except  for  the  following: 

On  the  ground  side,  both  MEUs  simultaneously  detected  mines  as  they 
approached  the  beach.  Since  MEU  2’s  attack  had  priority,  the  correct  response  was  for 
the  CJTF  to  give  MEU  2  the  mine  countermeasures  helicopters  first.  Each  assault  began 
immediately  after  the  mines  were  cleared  from  its  respective  beach.  Once  the  MEUs 
landed  on  the  beaches,  the  enemy  tank  column  and  mines  only  appeared  on  the  north 
road,  threatening  MEU  1.  There  was  no  competition  for  the  engineers  and  Cobras. 
Casualties  were  only  incurred  by  MEU  2,  so  there  was  no  competition  for  the 
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MEDEVAC  helicopter.  FROG  launchers,  however,  were  detected  simultaneously  by  both 
MEU  1  and  MEU  2,  causing  competition  over  the  CAS  aircraft.  Since  MEU  2  had 
priority,  the  correct  response  was  for  MEU  2  to  get  the  CAS  aircraft  first.  Finally,  as  the 
MEUs  approached  their  objectives,  it  became  clear  that  neither  would  be  able  to  take  its 
objective  without  reinforcements,  so  there  was  competition  over  the  JTF  reserve.  The 
correct  response  was  for  MEU  2  to  get  the  reserve  first,  then  MEU  1 .  Figure  8  depicts 
Module  2. 


64 


On  the  maritime  side,  the  enemy  submarine  was  detected  moving  toward  the 
CVBG  instead  of  both  the  CVBG  and  the  ARG,  eliminating  the  competition  over  the 
frigate.  The  enemy  helicopters  detected  preparing  to  take  off  were  only  within  range  of 
the  ARG,  not  the  CVBG,  eliminating  the  competition  over  the  Stinger  platoon.  There 
were  reports  of  two  Silkworm  sites  instead  of  one,  however,  one  threatening  the  CVBG 
and  the  other  threatening  the  ARG.  This  caused  competition  over  the  SR-71  and  CAS. 
Here,  the  SR-71  flyover  should  have  been  requested  first  for  the  CVBG  and  then  for  the 
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ARG.  Both  sites  were  confirmed  (simultaneously),  and  the  CVBG  should  have  gotten  the 
FA-18’s  first,  and  then  the  ARG.  The  report  of  the  air  attack  was  only  against  the  CVBG, 
eliminating  the  competition  over  the  AEGIS  cruiser.  Also,  no  CAP  aircraft  at  all  were 
available  for  the  second  coverage  period;  the  ARG  and  CVBG  then  competed  over  a 
section  of  CAP  aircraft  that  became  available  almost  immediately  from  the  JFACC.  The 
correct  response  was  for  the  ARG  to  get  the  JFACC  CAP,  because  the  air  attack  was  over 
and  it  the  ARG  had  priority.  Finally,  fast  patrol  boats  were  detected  moving  toward  both 
the  ARG  and  CVBG,  inducing  competition  over  the  SH-60s.  The  correct  response  was 
for  the  CVBG  to  get  the  SH-60  assets.  Module  4  is  depicted  in  Figure  9. 

9.  Development  of  Training  Scenarios 

In  order  to  familiarize  the  subjects  with  the  general  situation  in  the  scenarios,  the 
DDD  III  simulator,  the  operational  context,  and  activities  required  such  as  transferring 
assets  back  and  forth,  requesting  assets,  communicating  using  preformatted  message  sets, 
et  cetera,  I  created  training  scenarios  based  on  the  experimental  scenarios.  The  training 
scenarios  were  identical  to  the  experimental  scenarios,  except  that  they  did  not  contain 
any  competition  events.  I  developed  two  training  scenario  varieints,  each  composed  of  a 
ground  and  a  maritime  module,  and  designed  them  so  that  each  lower  level  unit  had  an 
opportunity  to  perform  each  subtask  and  use  every  asset.  For  example,  if,  in  one  training 
scenario,  MEU  1  killed  tanks  with  its  Cobra  helicopters,  then,  in  the  other  training 
scenario,  MEU  1  transferred  the  Cobras  to  MEU  2  to  destroy  tanks.  The  specific  training 
scenarios  are  described  below. 

a.  Training  Scenario  13 

MEU  2  detected  mines  as  it  approached  Blue  Beach,  and  had  to  clear 
them.  After  the  mines  had  been  cleared,  MEU  1  and  MEU  2  continued  their  coordinated 
attack  on  the  commanding  terrain.  Red  Beach,  and  Blue  Beach.  Once  the  beaches  were 
secure,  MEU  2  encountered  tanks  on  the  south  road,  and  needed  to  request  MEU  I’s 
Cobras.  MEU  1  then  needed  to  MEDEVAC  casualties,  and  requested  MEU  2’s 
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Figure  9.  Module  4:  Competition  Between  Maritime  Units  for  Non-Organic  Assets 


MEDEVAC  helicopter.  Subsequently,  MEU  1  encountered  mines  on  the  north  road,  and 
cleared  them  with  their  own  engineer  platoon. 

Meanwhile,  MEU  2  detected  a  FROG  launcher,  and  needed  to  request 
CAS  from  the  CJTF.  After  MEU  1  cleared  its  mines,  it  continued  the  attack  and  realized 
that  it  needed  reinforcements  in  order  to  capture  the  port.  MEU  1  then  requested  the 
reserve  from  the  CJTF.  When  MEU  2  reached  the  airfield,  it  conducted  a  coordinated 
attack  with  its  AAAV  company  and  its  helibome  company. 
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Throughout  the  training  scenarios,  artillery  targets  popped  up,  and  either 
MEU  1  or  MEU  2  needed  to  request  NSFS  from  the  CJTF  in  order  to  suppress  the 
targets. 

On  the  maritime  side,  the  ARG  was  threatened  by  a  submarine,  and 
requested  the  frigate  from  the  CVBG.  Meanwhile,  CAPs  were  launched  and  maintained 
above  the  ARG  and  CVBG.  Only  the  ARG  was  threatened  by  a  helicopter  attack,  and 
used  its  own  Stinger  platoon  to  defend  itself  Then,  an  inbound  air  attack  was  reported, 
but  only  threatened  the  CVBG,  which  defended  itself  with  the  AEGIS  cruiser  and 
requested  a  section  of  CAP  from  the  JFACC  (via  the  CJTF),  its  own  CAP  having  run  out 
of  fuel  by  then  with  no  others  available.  At  the  same  time,  patrol  boats  were  observed 
heading  toward  the  CVBG,  which  requested  the  SH-60’s  from  the  CJTF  in  order  to 
defend  itself  Finally,  the  ARG  was  threatened  by  a  Silkworm  launcher,  and  needed  to 
request  the  SR-71  imagery  and  a  section  of  CAS  from  the  CJTF  in  order  to  destroy  the 
launcher. 


b.  Training  Scenario  24 

This  was  identical  to  Training  Scenario  13,  but  “who  needed  which  asset” 
was  reversed.  MEU  1  needed  the  mine  countermeasures  helicopter  and  CAS  from  the 
CJTF,  and  needed  to  use  its  own  Cobras,  while  MEU  2  will  needed  to  request  the  reserve 
company  from  the  CJTF  and  the  engineer  platoon  from  MEU  1,  and  used  its  own 
MEDEVAC  helicopters. 

On  the  maritime  side,  the  CVBG  needed  to  request  the  SR-71  imagery  and 
CAS  from  the  CJTF  and  the  Stinger  platoon  from  the  ARG,  and  used  its  own 
anti-submarine  warfare  asset.  The  ARG  had  to  request  the  JFACC  CAP  and  the  SH-60s 
from  the  CJTF,  and  the  AEGIS  cruiser  from  the  CVBG. 

E.  GRADING  DIMENSIONS  OF  TASK  STRUCTURE  IN  SCENARIOS 

The  final  step  in  the  task  design  process,  after  drafting  the  scenarios  that  differ  in 
the  task  structure  dimension  of  interest  and  comply  with  the  desired  task  structure,  is  to 
grade  the  dimensions  of  task  structure  in  order  to  ascertain  whether  they  differ  and  are 
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held  constant  in  the  right  dimensions.  Below  Modules  1  and  2  are  compared  against  each 
other,  as  are  Modules  3  and  4. 


1.  Modules  1  and  2 

a.  Uncertainty 

The  main  issues  of  uncertainty  that  occur  in  both  modules  are  the  location 
of  the  tanks,  the  location  of  the  offshore  mines  and  mines  on  the  road,  the  enemy  strength 
at  the  port  and  the  airfield,  which  FROG  launchers  and  artillery  will  pop  up  and  when, 
and  the  location,  timing,  and  priority  of  MEDEVACs.  These  are  the  same  across  both 
modules,  so  uncertainty  in  Modules  1  and  2  is  constant,  and  graded  as  Medium. 

b.  Time  Pressure 

Time  pressure  varied  across  subtasks  within  modules,  but  was  constant 
across  the  modules,  since  subtasks  carried  the  same  time  pressure  scores  in  one  module  as 
they  did  in  another.  This  should  be  classified  as  Medium  overall,  for  both  modules. 

c.  Complexity 

Since  complexity  is  not  the  dimension  of  interest  in  this  experiment,  it  is 
not  necessary  to  decompose  it  into  its  five  characteristics  and  score  each  characteristic. 
The  attributes,  paths,  outcomes,  interdependence  of  outcomes,  and  probability  of  linkages 
were  all  basically  the  same  for  both  modules.  This  was  true  because  the  modules  both 
involved  the  same  subtasks  and  actions  —  the  difference  was  in  which  subtasks  were 
performed  twice.  In  Module  1,  the  subtasks  which  involved  competition  over  organic 
assets  were  performed  twice,  while  in  Module  2,  the  subtasks  which  involved 
competition  over  non-organic  assets  were  performed  twice.  Those  subtasks  were  quite 
similar  in  complexity  and  level  of  effort,  so  an  overall  score  for  comparison  purposes  is 
sufficient.  Both  Modules  1  and  2  are  of  Medium  complexity. 
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d.  Coordination  Requirements 

Coordination  requirements  was  the  task  structure  dimension  of  interest  for 
this  experiment.  The  grading  of  each  of  the  types  of  dependencies  present  is  as  follows: 

(1)  Shared  Resources.  As  previously  discussed,  the  shared 
resources  dependency  was  varied  in  Modules  1  and  2.  In  Module  1,  the  grade  for 
competition  over  internal  shared  resources  is  High,  and  the  grade  for  competition  over 
external  shared  resources  is  None.  In  Module  2,  the  grade  for  competition  over  internal 
shared  resources  is  None,  and  the  grade  for  competition  over  external  shared  resources  is 
High. 


(2)  Producer/Consumer  Relationships.  Although  there  are  more 
solid  arrows  (indicating  hard  prerequisites)  on  the  Module  1  diagram  (Figure  4)  than  on 
the  Module  2  diagram  (Figure  6),  the  number  of  subtasks  that  are  affected  by  these  solid 
arrows  is  in  both  cases  seven.  This  dependency  is  graded  as  Medium  for  both  modules. 

(3)  Simultaneity  Constraints.  This  dependency  is  also  graded  as 
Medium  for  both  modules.  Although,  in  Module  1,  the  Assault  on  Blue  Beach  subtask 
was  required  to  be  conducted  in  concert  with  the  Assault  on  Red  Beach  and  Air  Assault 
on  Commanding  Terrain  subtasks,  while  only  the  latter  two  subtasks  were  conducted  in 
concert  in  Module  2,  the  additional  coordination  required  for  that  parallelism  was 
negligible. 


(4)  Task/Subtask.  The  task/subtask  dependency  is  not  present  in 
either  module.  The  scenarios  were  given  to  the  players  in  “prescripted”  form,  to  a  large 
degree,  and  there  was  no  requirement  for  tasks  to  be  subdivided  among  actors. 

e.  Magnitude 

Magnitude  is  also  constant  across  tasks.  Both  Modules  1  and  2  contain  20 
subtasks  each,  and  most  of  these  subtasks  are  the  same  in  both  tasks.  The  difference,  as 
with  complexity,  is  in  which  subtasks  are  performed  twice.  The  subtasks  performed  twice 
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in  Module  1,  Conduct  MEDEVAC,  Kill  Tanks,  and  Clear  Mines,  require  a  total  of  12 
actions  per  pair  of  subtasks.  The  subtasks  performed  twice  in  Module  2,  Clear  Mines 
from  Beaches,  Kill  FROG  Launchers,  and  Reinforce  Attacks,  also  require  a  total  of  12 
actions  per  pair  of  subtasks.  Thus,  the  subtasks  are  equivalent,  since  they  all  require  the 
same  number  of  actions,  so  the  tasks  would  each  be  scored  as  20  on  a  “subtasks”  scale. 

f.  Resources  Required 

Module  1  and  Module  2  each  require  19  resources  to  complete  all 
subtasks,  so  resources  required  is  constant  across  tasks. 

g.  Information  Required 

Module  1  and  Module  2  each  require  21  separate  pieces  of  information  to 
complete  all  subtasks,  so  information  required  is  also  constant  across  both  tasks. 

h.  Task  Formalization 

Both  Module  1  and  Module  2  are  High  formalization.  The  subtasks  that 
must  be  completed  for  both  tasks  are  well  defined  and  well  structured,  and  there  are  clear 
paths  to  the  correct  solution. 

L  Dynamicity 

Dynamicity  is  High  for  both  tasks.  Almost  all  subtasks  within  both 
modules  would  change  over  time. 

2.  Modules  3  and  4 

a.  Uncertainty 

Uncertainty  in  Modules  3  and  4  is  Medium,  as  in  Modules  1  and  2.  The 
uncertainty  issues  that  occur  in  Modules  3  and  4  are  the  number  and  target  of  attacking 
submarines,  the  number  and  target  of  fixed  wing  and  rotary  wing  air  attacks,  the  number 
and  location  of  Silkworm  launchers,  and  the  number  and  target  of  attacking  patrol  boats. 
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b.  Time  Pressure 

The  time  pressure  characteristics  were  the  same  for  Modules  3  and  4  as 
they  were  for  Modules  1  and  2,  and  is  graded  as  Medium  for  both  modules. 

c.  Complexity 

Complexity  circumstances  were  the  same  for  these  modules  as  they  were 
for  Modules  1  and  2.  Complexity  is  graded  as  Medium  for  Modules  3  and  4  as  well. 

d.  Coordination  Requirements 

(1)  Shared  Resources.  This  is  the  same  as  it  was  for  Modules  1 
and  2.  In  Module  3,  the  grade  for  competition  over  internal  shared  resources  is  High,  and 
the  grade  for  competition  over  external  shared  resources  is  None.  In  Module  4,  the  grade 
for  competition  over  internal  shared  resources  is  None,  and  the  grade  for  competition 
over  external  shared  resources  is  High. 

(2)  Producer/Consumer  Relationships.  There  are  six  solid  arrows 
in  both  the  Module  3  and  Module  4  diagrams,  indicating  6  producer/consumer 
relationships  between  subtasks  within  each  task.  This  dependency  is  graded  as  Medium 
for  both  modules. 


(3)  Simultaneity  Constraints.  This  dependency  is  also  graded  as 
Medium  for  both  modules.  There  are  a  total  of  three  solid  bars  indicating  parallel 
activities  in  each  of  the  two  modules. 

(4)  Task/Subtask.  As  was  true  in  Modules  1  and  2,  the 
task/subtask  dependency  is  not  present  in  either  of  these  two  modules. 

e.  Magnitude 

Magnitude  is  again  considered  constant  over  both  Modules  3  and  4, 
although  Module  3  has  21  subtasks  and  Module  4  has  22.  The  difference  occurred 
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because  two  of  the  competition  events  in  Module  4,  Identifying  and  Striking  Silkworm 
Sites,  required  the  subtasks  to  be  performed  twice,  while  all  the  other  competition  events 
in  these  two  modules  were  only  performed  once.  However,  the  first  subtask  in  a  two 
competitive  subtask  chain,  such  as  the  two  “Strike  Silkworm  Site”  subtasks  in  Module  4 
and  all  the  competitive  subtasks  in  Modules  1  and  2,  requires  twice  as  many  actions  as 
the  second  subtask  in  the  chain,  because  the  first  subtask  is  where  the  recognition  and 
resolution  of  the  competition  actually  occurs.  The  second  subtask  in  the  chain, 
performing  the  lower-priority  subtask,  is  merely  a  “push-button”  subtask,  requiring  little 
decisionmaking  skill.  Thus,  adding  an  extra  subtask  in  Module  4  was  considered  of 
relatively  little  significance. 

/.  Resources  Required 

Module  3  and  Module  4  each  require  20  resources  to  complete  all 
subtasks,  so  resources  required  is  constant  across  tasks. 

g.  Information  Required 

Module  3  and  Module  4  each  require  24  separate  pieces  of  information  to 
complete  all  subtasks,  so  information  required  is  also  constant  across  both  tasks. 

h.  Task  Formalization 

Modules  3  and  4  contain  the  same  characteristics  as  Modules  1  and  2,  and 
are  also  graded  as  High  formalization. 

L  Dynamicity 

Dynamicity  is  again  High  for  both  tasks.  Almost  all  subtasks  within  both 
modules  would  change  over  time. 
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F.  CONDUCT  OF  EXPERIMENT 


1.  Experiment  Setup 

a.  Physical 

The  six  test  subjects  for  each  team  were  presented  the  scenario  on  a 
distributed,  interactive,  computer  simulation  running  on  seven  SUN  SPARC™ 
workstations.  (The  seventh  station  was  the  experimenter’s  station.)  The  facility  used  was 
the  Systems  Technology  Laboratory  at  the  Naval  Postgraduate  School  in  Monterey,  CA. 
Although  all  subjects  were  in  the  same  room,  dividers  were  placed  between  them,  and  (to 
facilitate  subsequent  data  analysis)  communications  among  subjects  was  restricted  to 
preformatted  computer  messages  built  into  the  simulator. 

b.  Lead  Team 

A  group  of  eight  NPS  officer  students  from  the  Joint  C4I  Systems,  Space 
Systems  Operations,  and  Operations  Research  curricula  were  designated  as  the  “lead 
team”  for  this  experiment.  Three  of  the  members  of  the  lead  team  were  so  designated 
because  their  theses  involved  the  experiment;  the  other  five  were  enrolled  in  CC4103, 
“Evaluation  of  Command  and  Control  Systems,”  a  required  course  in  the  Joint  C4I 
Systems  curriculum,  of  which  the  conduct  of  this  experiment  was  an  integral  part.  The 
lead  team  was  composed  of  officers  from  all  four  branches  of  the  armed  forces,  and  all 
members  had  recent  operational  experience.  The  author  headed  the  lead  team. 

The  lead  team  performed  such  tasks  as  preparation  of  training  materials 
for  the  subjects,  conduct  of  subject  training,  setup  of  the  physical  space,  debugging  the 
simulator  and  the  scenario’s  implementation  in  the  simulator,  conduct  of  the  experimental 
runs,  and  data  collection.  The  lead  team  also  provided  invaluable  suggestions  and  advice 
concerning  all  of  the  above  subjects  as  well  as  scenario  development,  and  filled  many 
gaps  in  the  author’s  experience. 
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c. 


Test  Subjects  Used 


The  test  subjects  were  24  military  officer  students  from  the  Joint  C4I 
Systems  curriculum  at  NFS.  The  subjects  were  organized  into  four  six-person  teams.  The 
teams  were  formed  by  the  experimenters  with  participants  distributed  according  to 
military  occupational/warfighting  specialty  and  branch  of  service,  to  the  extent  that  that 
was  possible  given  the  demographics  of  the  sample. 

Since  there  was  a  fairly  significant  difference  between  the  operational 
experience  of  the  subjects,  the  experimenters  were  concerned  that  some  subjects  would  be 
more  familiar  than  others  with  the  appropriate  tactics  to  employ  in  a  given  situation,  and 
that  this  might  have  an  undesirable  effect  on  the  performance  measures  chosen  as 
dependent  variables.  In  order  to  counter  such  an  impact,  the  scenarios  and  the  operations 
order  were  tailored  to  facilitate  a  “cookbook”  approach  to  each  situation.  This  approach 
further  aided  the  experimenters’  attempt  to  steer  the  subjects  toward  the  competition 
events  that  were  of  prirhary  interest  in  the  experiment. 

d.  Simulator 

The  experiment  was  conducted  using  the  Distributed  Dynamic 
Decisionmaking-III  (DDD-III)  simulator.  Earlier  variants  of  the  DDD  had  been  used 
extensively  in  the  past  to  study  decisionmaking  in  the  Navy’s  Composite  Warfare 
Commander  (CWC)  organizational  structure.  In  a  concomitant  effort,  the  DDD  was 
extended  to  fit  the  general  requirements  of  tier-I  experimentation  for  the  A2C2  project, 
and  was  adapted  to  meet  the  specific  requirements  of  the  current  experiment.  Although  it 
is  not  a  tactical  model  on  the  level  of  RES  A,  JTLS,  MTWS,  CBS,  or  AWSIM,  it  contains 
data  collection  and  variable  manipulation  capabilities  that  make  it  very  appropriate  for  a 
research  environment.  For  a  more  detailed  treatment  of  DDD-III,  its  characteristics,  and 
implementation  in  DDD-III  of  the  scenarios  and  organizational  structures  used  in  this 
experiment,  see  Higgins  (1996). 
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e.  Matching  of  Subjects  to  Task/Organization  Structure 

The  experimental  team  decided  to  keep  the  subjects  in  the  same  position  in 
the  organization  structure  through  all  of  the  training  and  data  runs;  if  a  subject  began  the 
training  runs  as  the  CJTF  for  his  team,  for  example,  he  would  remain  CJTF  throughout 
the  experiment.  The  only  position  for  which  this  was  not  possible  was  the  GCC/MCC 
position.  Since  half  the  experimental  and  training  runs  used  a  GCC,  and  the  other  half 
used  an  MCC,  the  individual  who  played  this  position  would  switch  back  and  forth 
accordingly.  This  caused  problems,  as  will  be  discussed  in  the  lessons  learned  section  of 
this  chapter. 

To  the  greatest  degree  possible,  the  experimenters  and  lead  team  attempted 
to  match  the  subjects  to  positions  in  the  organizational  structure  for  which  they  had  some 
operational  experience.  For  instance,  the  MEUs  were  played  by  Marine  and  Army 
officers,  and  the  CVBG  and  ARG  were  played  by  Navy  pilots  and  surface  warfare 
officers.  Unfortunately,  our  sample  was  heavy  in  Navy  officers,  which  meant  that  all  of 
the  MCC/GCC  players  were  naval  officers.  This  was  not  an  issue  when  the  intermediate 
level  of  hierarchy  was  an  MCC,  but  caused  difficulty  when  the  intermediate  level  was  a 
GCC.  This  will  also  be  discussed  in  the  lessons  learned  section. 

2.  Operationalization  of  Task/Organization  Structures 

The  organization  structures  shown  in  Figure  4  and  the  task  structures  shown  in 
Figures  6  through  9  were  operationalized  in  three  significant  respects:  through  asset 
structure,  communications  structure,  and  information  structure. 

a.  Asset  Structure 

The  scenarios  were  designed  so  that  if  a  unit  must  perform  a  specific  task, 
then  the  assets  required  should  be  transferred  to  that  unit,  rather  than  the  original  owner 
attempting  to  perform  the  task  for  the  unit  that  required  the  asset.  For  example,  if  MEU  2 
was  under  attack  by  a  tank  colunrn,  the  experimenters  wanted  MEU  1  to  transfer  the 
necessary  asset  (the  Cobra  helicopters)  to  MEU  2  to  destroy  the  tanks,  rather  than  MEU  1 
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destroy  the  tanks  itself.  This  was  done  to  ensure  that  the  proper  competition  events 
actually  occurred,  and  led  to  the  issue  of  transferability. 

All  assets  in  the  scenario  were  transferable,  with  few  exceptions.  The 
nontransferable  assets  included  such  assets  as  the  amphibious  shipping  and  the  aircraft 
carrier,  which  were  not  directly  needed  to  accomplish  competitive  tasks.  All  assets  shown 
on  Table  3  were  transferable  by  their  owners. 

If  the  asset  owner  chose  not  to  transfer  an  asset  as  requested  by  a  unit 
needing  it,  a  higher-level  decisionmaker  could  force  transfer  of  the  asset(s).  For  example, 
if  the  ARG  requested  an  asset  from  the  CVBG,  and  the  CVBG  ignored  the  request,  the 
MCC  (if  present)  or  CJTF  could  forcibly  transfer  the  asset  from  the  CVBG  to  the  ARG,  if 
he  determined  that  the  ARG’s  need  for  the  asset  outweighed  that  of  the  CVBG. 

While  all  organic  assets  were  owned  by  the  lower  level  units  (the  MEUs, 
the  ARG,  or  the  CVBG),  all  non-organic  assets  were  ovmed  by  the  CJTF.  No  assets 
began  the  scenario  under  the  ownership  of  the  GCC  or  MCC.  This  was  contrary  to  logic, 
because  some  non-organic  assets  were  component  specific,  and  should  have  naturally 
been  under  the  control  of  the  GCC  or  MCC,  if  present.  An  example  is  the  SH-60  ASUW 
helicopters  —  if  the  MCC  was  present,  he  should  have  controlled  the  asset,  because  there 
is  no  conceivable  use  to  which  the  ground  component  could  have  put  the  asset.  If  the 
MCC  was  not  present  in  the  structure,  though,  the  asset  would  have  been  under  the 
control  of  the  CJTF.  It  was  for  this  reason  that  all  non-organic  assets  were  kept  under  the 
control  of  the  CJTF  —  the  experimenters  did  not  want  the  assets  shifting  back  and  forth 
between  the  CJTF  and  intermediate  commanders  for  the  different  organization  structures, 
but  wanted  to  keep  the  asset  structure  constant. 

b.  Communications  Structure 

Communications  in  this  experiment  were  limited  to  preformatted 
messages  using  the  DDD-III  simulator.  No  verbal  communications  were  allowed. 

Copies  of  all  messages  sent  by  a  decisionmaker  were  automatically 
forwarded  to  the  next  higher  level  in  the  hierarchy.  If  a  lower-level  unit,  such  as  MEU  1, 
communicated  with  another  low-level  unit,  such  as  MEU  2,  a  copy  of  the  message  was 
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sent  to  the  intermediate  commander.  In  this  case,  that  is  the  GCC  (if  present)  or  the  CJTF. 
And,  if  the  intermediate  level  commander  communicated  with  a  lower  level  unit,  a  copy 
of  his  message  was  forwarded  to  the  CJTF. 

When  an  intermediate  level  commander  was  present,  the  low-level  units 
could  not  communicate  directly  with  the  CJTF.  In  such  cases  communications  followed 
the  chain  of  command  via  the  MCC  or  GCC,  as  the  case  may  be. 

c.  Information  Structure 

One  of  the  major  assumptions  behind  the  “flattening”  concept  discussed 
earlier  is  the  existence  of  a  common  operational  picture  (COP).  All  commanders  at  all 
levels  must  have  a  common  view  of  the  battlespace  they  must  see  the  same  threats,  at  the 
same  time.  Since  our  purpose  was  to  test  organizational  structures  in  a  future  environment 
of  shared,  global  information,  the  COP  was  one  of  the  givens  of  our  experiment.  When 
one  decisionmaker  in  the  organization  saw  a  threat  or  task,  it  was  seen  by  all  others  at  the 
same  time.  It  was  felt  that  this  common  view  might  reduce  parochialism  in  certain 
circumstances,  through  fostering  of  shared  mental  models  among  team  members. 

3.  Training 

The  experimental  team  felt  that  the  proper  training  of  the  subjects  in  the  operation 
of  the  simulator  and  the  requirements  of  the  operations  order  (OPORDER)  was  vital  to 
the  success  of  the  data  runs.  Two  aspects  of  this  training  were  significant:  the  training 
materials  that  the  lead  team  and  experimental  team  generated,  and  the  conduct  of  the 
training  itself 


a.  Training  Materials 

The  lead  team  and  experimental  team  developed  three  primary  training 
aids  for  the  training  portion  of  the  experiment:  an  OPORDER  which  transformed  the 
scenarios  developed  by  the  lead  team  into  a  directive  for  execution  of  an  operation,  a 
tutorial  designed  to  aid  the  subjects  in  using  the  DDD-III  to  implement  the  OPORDER, 
and  the  scenarios  developed  for  the  training  portion  of  the  experiment. 


78 


(1)  Operations  Order.  When  a  military  operation  or  exercise  is 
conducted,  an  OPORDER  is  given  as  an  implementation  directive.  This  OPORDER  tells 
the  unit(s)  that  will  conduct  the  operation  or  exercise  the  general  situation,  enemy  forces, 
friendly  forces  available,  the  mission,  how  the  mission  will  be  executed,  and  logistics  and 
command  and  control  information.  Since  this  was  the  language  that  the  subjects  spoke, 
the  experiment  team  determined  that  the  information  that  the  subjects  needed  to  execute 
the  scenario  should  be  given  in  that  format. 

(2)  Tutorial.  The  tutorial  was  the  link  between  the  OPORDER  and 
the  DDD-III.  It  described  the  simulator  to  the  subjects  and  its  display  and  user  interface, 
functions  of  the  mouse,  requesting,  launching,  moving  and  transferring  assets,  identifying 
and  attacking  threats,  and  use  of  communications  messages.  The  tutorial  also  listed  and 
described  in  detail  all  the  objects  that  appear  on  the  DDD-III  screen,  including  friendly 
and  enemy  assets  and  terrain  features,  and  gave  a  detailed  description  of  the  organization 
structures  used  in  the  experiment  and  how  they  are  implemented  in  DDD-III.  Finally,  the 
tutorial  included  a  single-page  “cheat  sheet”  for  use  as  a  quick  reference  that  concisely 
described  all  the  objects  on  the  screen  and  assets  that  must  be  used  to  destroy  enemy 
threats,  abbreviations  used  by  DDD,  and  a  list  of  assets,  the  platforms  on  which  they  are 
carried,  and  how  each  asset  is  used. 

(3)  Training  Scenarios.  The  training  scenarios,  described  in 
Section  D  of  this  chapter,  were  devised  to  help  the  subjects  learn  about  the  simulator  and 
OPORDER,  and  allow  them  to  become  proficient  in  the  skills  that  would  enable  them  to 
compete  over  assets  and  successfully  resolve  the  competition.  The  experimenters  did  not, 
however,  want  to  “spoil”  the  competition  events  that  would  occur  in  the  data  runs,  so  the 
training  scenarios  had  to  be  devised  with  care  to  not  include  competition  events.  These 
scenarios  were  written  by  the  author,  with  advice  and  assistance  from  the  lead  and 
experimental  teams.  Refer  to  Section  D  for  details  of  the  scenarios  that  were  developed. 
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b.  Conduct  of  Training 

Initially,  the  subjects  were  given  a  one-hour  brief  in  a  classroom  on  the 
fact  that  they  were  taking  part  in  an  experiment  (no  experimental  objectives  were 
included),  the  OPORDER,  the  organization  structures  they  would  be  using,  and  the 
DDD-III.  The  purpose  of  this  brief  was  only  to  give  the  subjects  a  general  overview  of 
what  they  would  be  doing  during  the  training  and  experiment  runs,  and  to  give  them 
some  context  for  the  training  runs.  The  training  runs  were  then  conducted  as  previously 
mentioned,  using  the  training  scenarios  which  contained  no  competition  events,  but  in 
aggregate,  had  a  requirement  for  all  of  the  subjects  to  use  all  the  assets  within  each 
component.  During  the  training  runs,  four  members  of  the  lead  team  were  present  to 
assist  each  team  of  subjects  in  familiarizing  themselves  with  the  simulator  and 
OPORDER. 

4.  Experiment  Conduct 

The  experiment  took  place  during  the  weeks  of  4-8  March  and  11-15  March  1996. 
Two  of  the  four  teams  were  run  through  the  experiment  each  week.  Each  team  completed 
four  training  runs,  followed  by  four  trials  during  which  data  was  collected  (one  for  each 
task/organization  structure  combination),  in  a  total  of  four  two-hour  sessions  per  team. 
The  training  runs  and  the  data  collection  runs  were  each  40  minutes  long,  interrupted 
twice  for  situational  awareness  probes.  In  order  to  compensate  for  any  learning  effects, 
the  data  collection  trials  were  counterbalanced  so  that  each  team  encountered  the  four 
conditions  in  a  different  order,  and  each  condition  appeared  in  each  place  in  the  order 
exactly  once,  as  shown  in  Figure  10.  At  least  three  members  of  the  lead  team  were 
present  at  all  times  during  the  data  collection  runs,  to  monitor  the  subjects  and  collect 
data. 
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Figure  10.  Counterbalancing  of  Trials  for  First  A2C2  Experiment 


G.  SUMMARY 

The  task  design  process  described  in  Chapter  III  was  implemented  in  this  chapter 
to  solve  the  task/scenario  design  problem  for  the  initial  A2C2  experiment.  First,  the 
experimental  designers  determined  the  task  structure  dimension  of  interest  and  desired 
structural  characteristics  of  the  task  from  previous  research.  Next,  I  iteratively  developed 
scenarios  using  the  task  structure  description  paradigm  generated  in  Chapter  III  that 
complied  with  the  experimental  designers’  requirements.  This  was  done  within  the 
constraints  of  the  dimensions  of  task  structure  defined  in  Chapter  II.  Then,  I  graded  the 
completed  scenarios  based  on  the  grading  scheme  delineated  in  Chapters  II  and  III,  to 
ensure  that  the  experimental  objectives  had  been  met.  Finally,  I  described  the  experiment 
that  was  conducted  using  the  scenario  developed  in  this  chapter,  including  further 
discussion  of  the  operationalization  of  the  scenarios  and  organization  structures. 

Chapter  V  will  include  a  discussion  of  the  lessons  learned  from  the  experiment 
with  regard  to  scenario  design,  and  from  the  above  implementation  of  the  scenario  design 
process.  It  will  conclude  with  a  summary  of  the  issues  discussed  in  this  thesis. 
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V.  LESSONS  LEARNED  AND  SUMMARY 


Upon  completion  of  the  experiment,  based  on  the  observations  of  the 
experimenters  and  the  lead  team,  it  was  clear  that  there  were  some  ways  in  which  the 
experiment  and  the  task  design  process  discussed  in  this  thesis  could  have  been  better 
implemented.  I  will  focus  here  only  on  the  items  that  are  of  specific  interest  to  the 
task/organization  structure  and  scenario  development  process. 

Following  discussion  of  lessons  learned,  I  will  provide  a  brief  summary  of  the 

thesis. 


A.  LESSONS  LEARNED  FROM  SCENARIO  DEVELOPMENT  PROCESS 
1 .  T radeoff  Between  Realism  and  Competition 

a.  One-of-a-Kind  Assets 

Several  complaints  were  received  from  our  more  operationally  astute 
subjects  concerning  the  scenario’s  lack  of  realism.  This  was  a  difficult  issue,  and  the 
experimenters  struggled  with  it  during  scenario  design.  If  the  specific  competition  events 
of  interest  were  to  be  induced  in  a  consistent,  repeatable  manner,  the  scenario  would  have 
to  force  the  use  of  one  asset  to  perform  a  certain  task.  This  is  inherently  unrealistic,  since 
joint  task  forces  commonly  have  several,  or  even  many,  different  assets  that  could 
perform  a  given  task.  However,  had  we  designed  the  scenario  to  more  accurately  reflect 
the  real  world,  then  the  teams  could  have  in  essence  created  their  own  task  structures,  and 
avoided  entirely  the  competition  events  that  were  the  focus  of  the  experiment.  In 
retrospect,  it  would  have  been  useful  to  make  the  competition  involve  a  combination  of 
assets,  rather  than  a  single  asset.  The  tradeoff,  though,  is  that  that  would  have  made 
scenario  development  much  more  complex,  and  would  have  increased  the  probability  that 
operational  background  and  “weaponeering”  skill  would  have  an  undesirable  effect  on  the 
variables  of  interest. 
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b.  Hard  Prerequisites 

Designing  the  implementation  of  the  scenario  in  the  simulator  so  that 
certain  activities  must  be  performed  before  others  can  (hard  prerequisites)  is  helpful  for 
ensuring  that  a  team  follows  a  desired  task  structure.  However,  like  the  design  of 
one-of-a-kind  assets,  development  of  hard  prerequisites  carries  a  price  in  terms  of 
realism,  and  the  value  of  strictly  following  a  desired  task  structure  must  be  weighed 
against  the  value  of  allowing  a  team  to  make  mistakes  or  solve  problems  in  its  own  way, 
and  studying  the  team’s  mistakes  or  alternate  paths. 

2.  Requirement  of  Modules  to  Describe  Similar  Missions 

As  discussed  in  Chapter  IV,  each  scenario  was  developed  in  two  parts,  a  ground 
module  and  maritime  module.  It  was  desired  that  the  tasks  described  in  these  modules  be 
identical  in  dimensions  of  task  structure  and  physical  structure  of  the  task  within 
scenarios,  because  of  the  experimenters’  desire  to  separate  the  modules  for  analysis 
purposes  in  order  to  double  the  number  of  data  points  —  thus.  Modules  1  and  3  would 
have  to  be  identical,  and  Modules  2  and  4  would  have  to  be  identical.  However,  the 
nature  of  the  missions  of  the  groimd  component  (amphibious  assault  —  offensive  in 
nature)  and  maritime  component  (support  the  amphibious  assault  —  defensive  and 
logistic  in  nature)  were  quite  different.  Although  the  dimensions  of  task  structure  and  the 
task  structure  diagrams  for  each  module  were  identical  or  nearly  so  within  scenarios,  this 
fundamental  difference  in  the  missions  required  a  far  different  mindset  on  the  part  of  the 
players  for  the  conduct  of  each  task,  and  negatively  affected  the  experimenters’  ability  to 
consider  modules  identical  within  scenarios.  It  is  my  belief  that,  because  of  the  difference 
in  nature  of  air,  land,  and  sea  combat,  and  the  parts  each  play  in  joint  operations,  this 
problem  is  not  surmountable  within  the  bounds  of  operational  realism.  Therefore,  I 
believe  that  the  modular  approach  to  scenario  development  should  either  be  abandoned  or 
that  component  (land,  sea,  or  air)  be  analyzed  as  a  factor  along  with  task  and/or 
organization  structure.  Additionally,  a  further  dimension  of  task  structure  could  be  added 
to  the  current  list  of  nine:  Nature  of  Mission  or  Nature  of  Task. 
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3.  Span  of  Control  Not  Taxed 

There  were  not  enough  lower  level  units  in  the  organization  structures  used  for  the 
CJTF  to  require  an  intermediate  level  commander.  Since  four  people  is  not  too  many  for 
an  individual  to  supervise  —  his  span  of  control  was  not  taxed  —  he  received  no  real 
benefit  from  the  presence  of  an  intermediate  level  of  hierarchy.  In  fact,  because  the  asset 
structure  discussed  above  required  that  all  non-organic  assets  be  retained  at  the  CJTF 
level  rather  than  delegated  to  the  intermediate  commander  (when  present)  to  do  with  as 
he  saw  fit,  the  intermediate  commander  constituted  a  significant  roadblock  to  mission 
performance  when  the  JTF  was  competing  over  non-organic  assets.  Possible  solutions 
would  include  increasing  the  number  of  lower  level  units  in  each  component  or 
increasing  the  number  of  components.  The  added  units  could  come  from  either  increasing 
the  pool  of  subjects,  requiring  members  of  the  lead  team  to  function  as  confederates,  or 
implementing  additional  units  in  software. 

4.  Additional  Dimensions  of  Task  Structure 

Based  on  lessons  learned  from  the  first  A2C2  experiment,  there  are  two  additional 
dimensions,  abstraction  perspective  and  task  significance,  that  an  extension  of  the 
definitions  of  dimensions  of  task  structure  could  incorporate  for  future  experiments. 

a.  Abstraction  Perspective 

Abstraction  perspective  refers  to  the  context  from  which  an  activity  is 
viewed.  When  a  task  is  viewed  from  the  highest  level  in  an  organization  structure,  the 
task  may  involve  a  different  set  of  cognitive  skills  and  activities  than  when  it  is  viewed 
fi’om  the  lowest  level  in  an  organization  structure.  For  example,  an  amphibious  assault, 
when  viewed  fi-om  the  highest  level  in  the  hierarchy,  involves  such  activities  as  planning, 
subtask  decomposition  and  assignment,  and  resource  allocation.  When  viewed  from  the 
lowest  levels  in  the  hierarchy,  the  task  involves  performing  assigned  subtasks,  keeping 
superiors  informed,  requesting  further  orders/interpretations,  et  cetera.  Representation  in 
the  task  structure  diagram  of  the  perspective  from  which  a  task  or  subtask  is  viewed  and 
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the  activities  that  must  be  performed  from  that  perspective  would  improve  the 
development  of  task  structures  in  future  experiments.  (Kemple,  et  al.,  1996b) 

b.  Task  Significance 

Task  significance  was  defined  by  Davis  et  al.  (1991)  as  the  value  of  the 
task  output  to  the  organization  performing  the  task,  and  the  interdependency  between  task 
outputs  and  other  operations  of  the  organization.  I  purposely  left  this  out  of  the 
dimensions  defined  in  Chapter  II.  However,  it  can  be  argued  with  some  validity  that  the 
Modules  2  and  4  tasks  (the  maritime  tasks)  described  in  Chapter  IV  are  less  significant 
than  the  Modules  1  and  3  tasks  (the  ground  tasks),  since  the  ground  objectives  have 
priority,  and  this  difference  in  task  significance  could  confound  analysis.  Task 
significance  should  be  accounted  and  controlled  for  in  future  experiments  in  order  to 
address  this  issue.  It  would  probably  be  best  included  in  a  Nature  of  Task  dimension 
discussed  in  subsection  2  above. 

B.  LESSONS  LEARNED  FROM  CONDUCT  OF  THE  EXPERIMENT 

1.  MCC/GCC  Player  Should  Not  Alternate 

The  manner  in  which  two  organization  structures  were  implemented,  with  the 
middle  level  of  hierarchy  alternating  between  GCC  and  MCC,  was  the  source  of  some 
difficulty.  First,  the  fact  that  one  subject  alternated  between  two  positions,  while  all  of  the 
other  subjects  stayed  in  the  same  position  throughout  the  experiment,  meant  that  the 
GCC/MCC  subject  knew  each  of  his  positions  less  well  than  his  teammates  knew  theirs. 
Second,  in  an  actual  JTF,  the  GCC  or  MCC  could  reasonably  be  expected  to  be  a  subject 
matter  expert,  and  would  probably  be  the  senior  ground  or  maritime  officer  in  the  JTF. 
That  was  not  the  case  in  this  experiment.  Since  the  same  subject  was  both  GCC  and 
MCC,  he  had  to  be  either  a  Navy  officer  or  a  ground  officer.  Because  of  the  demographic 
makeup  of  the  subject  pool,  the  experimental  team  was  forced  to  use  exclusively  Navy 
officers  for  the  GCC/MCC  position.  While  these  officers  had  considerable  expertise  in 
maritime  affairs,  they  were  less  expert  on  ground  affairs  than  their  subordinate  MEU 
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since  the  decisions  that  these  Navy  officers  could  be  expected  to  make  while  MCC  would 
be  based  on  a  strong  operational  background,  while  those  made  while  in  the  GCC  position 
would  not.  A  potentially  alleviating  solution  would  be  to  use  different  officers  for  the  two 
positions,  with  a  Navy  officer  as  MCC  and  a  ground  officer  as  GCC. 

Another  option  could  be  to  change  the  organizational  structures  to:  (1)  CJTF  with 
only  lower  level  units  and  (2)  CJTF  with  the  same  number  of  lower  level  units,  but  a 
component  commander  supervising  each  component.  Although  there  are  fewer  subjects  in 
the  first  structure  than  the  second,  that  drawback  could  be  outweighed  by  the  ability  to 
more  clearly  see  the  results  of  the  flattened  versus  the  hierarchical  organizational  structure 
through  more  general,  whole-force  performance  measures,  rather  than  measures  directed 
specifically  at  one  component.  It  would  also  allow  for  the  GCC  to  only  perform  as  the 
GCC,  and  the  MCC  as  the  MCC,  and  for  each  to  be  from  a  service  which  specializes  in 
that  type  of  action,  and  would  better  manipulate  the  CJTF’s  span  of  control. 

2.  Increase  Time  Pressure 

Additional  time  pressure  would  have  improved  the  experiment.  Two  of  the  four 
teams  operated  under  a  reasonable  amount  of  time  pressure.  The  other  two  teams  were 
composed  of  more  operationally  proficient  members,  and  worked  under  relatively  low 
time  pressure.  These  two  more  operationally  proficient  teams  tended  to  “max  out” 
performance  measures,  making  it  difficult  to  find  any  difference  between  factor  levels.  A 
solution  would  have  been  to  increase  time  pressure  by  increasing  the  simulator  speed  or 
increase  the  number  of  activities  within  each  module. 

3.  Increased  Number  of  Competition  Events 

Each  scenario  module  contained  3  or  4  competition  events.  It  would  have  been 
useful  to  increase  that  to  5  or  6,  or  even  more,  to  increase  the  number  of  data  points. 

4.  Team  Formation 

One  difficulty  encountered  during  the  conduct  of  the  experiment  was  the  disparate 
levels  of  experience  among  the  subjects.  Those  officers  with  significant  operational 
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Team  Formation 


One  difficulty  encountered  during  the  conduct  of  the  experiment  was  the  disparate 
levels  of  experience  among  the  subjects.  Those  officers  with  significant  operational 
experience  and  the  “operational  mindset”  much  more  easily  adapted  themselves  to  the 
scenario  than  those  without  that  experience  or  mindset,  and  tended  to  perform  better.  This 
extreme  performance  variability  made  it  difficult  to  craft  tasks  that  maintain  a  reasonably 
constant  level  of  difficulty  across  teams  and  individuals.  Possible  solutions  would  be  (1) 
make  the  scenarios  less  realistic  and  less  operationally  relevant,  and  more  oriented  toward 
abstracted  decisionmaking,  somewhat  leveling  the  playing  field,  (2)  additional  training  of 
teams,  (3)  exclusion  of  subjects  without  some  relevant  operational  experience,  or  (4) 
finding  some  way  to  include  the  specialties  of  the  non-operationally  oriented  in  the 
scenarios.  Of  the  solutions,  (1)  is  not  practical  or  desired.  The  direction  of  these  A2C2 
experiments  should  and  will  go  toward  more  realism,  not  less,  although  at  a  higher  level, 
as  the  experimenters  attempt  to  gain  insight  into  A2C2  in  a  joint  operational-level  context 
with  more  senior  players.  Solution  (4)  would  be  difficult,  because  of  the  variety  of 
experiences  of  the  non-operationally  oriented.  The  lack  of  operational  orientation  was 
only  a  problem,  in  this  case,  with  the  Navy  OCS  officers.  The  Navy  and  Air  Force  do  not 
have  a  real  operational  training  baseline  for  many  of  their  officers  who  do  not  attend  a 
service  academy  or  ROTC.  If  these  officers  are  not  in  an  operational  specialty,  then  they- 
tend  to  have  little  or  no  exposure  to  operational  issues.  This  is  not  the  case  with  Marine 
or,  to  a  lesser  extent.  Army  officers,  who  receive  a  common  operational  training  baseline 
at  various  service  schools.  Implementing  solution  (4)  in  this  case  would  have  required 
that  a  job  be  found  for  a  legal  officer,  an  instructor  at  Nuclear  Power  School,  and  a 
communications  officer,  all  with  little  or  no  knowledge  of  how  the  Navy  fights,  and  this 
would  have  been  very  difficult  to  do.  Solution  (2)  would  also  be  difficult,  because  the 
amount  of  training  required  to  bring  a  non-operationally  experienced  officer  to  the  level 
of  one  Nvith  operational  experience  is  not  trivial.  Solution  (3),  exclusion  fi-om  the  sample 
of  Navy  and  Air  Force  officers  without  either  operational  experience  or  who  had  not 
attended  a  service  academy  or  ROTC,  is  probably  the  most  practical. 
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Officers  who  were  operationally  experienced,  but  played  a  role  in  the  experiment 
outside  of  their  area  of  expertise  did  not  tend  to  function  as  well  as  their  subordinates  who 
were  in  their  area  of  expertise.  This  was  most  specifically  a  problem,  as  was  mentioned 
earlier,  in  the  MCC/GCC  realm.  The  fact  that  all  the  MCC/GCC  players  were  Navy 
officers  made  judging  the  effect  of  the  extra  level  of  hierarchy  more  difficult,  because  the 
organizations  tended  to  perform  better  when  the  middle  level  of  hierarchy  was  on  the 
maritime  side,  as  would  be  expected  when  Navy  officers  were  playing  that  role.  The 
designers  of  future  A2C2  experiments  must  ensure  that  great  care  is  taken  to  match 
operational  experience  to  the  position  played  in  the  organizational  structure,  since  those 
future  experiments  will  likely  see  di  greater  level  of  operational  fidelity,  not  less. 

5.  Training  and  Planning 

Some  of  the  teams  of  subjects,  particularly  those  with  greater  operational 
experience,  approached  the  experiment  as  an  exercise,  in  which  they  wanted  to  optimize 
their  performance.  These  teams  conducted  their  own  “team”  training  prior  to  the  data 
runs;  they  went  over  the  OPORDER  together,  discussed  its  interpretation  and 
implications,  and  formulated  a  plan  within  the  plein  that  was  provided  to  them  in  the 
scenario.  Other  teams  did  not  do  this,  but  approached  the  experiment  in  more  of  a 
“cookbook”  fashion,  in  which  the  teams  took  the  plan  that  was  given  them  and  executed 
it  based  on  the  training  conducted  by  the  lead  team,  doing  no  further  coordination, 
planning,  or  training  on  their  own.  The  scenario  was  designed  assuming  the  subjects 
would  take  the  second  approach.  It  was  thought  that,  if  the  subjects  did  much  of  the 
planning  on  their  own,  they  would  create  their  own  task  structures  rather  than  follow  the 
task  structures  that  produced  the  competition  events  that  the  experimenters  were 
interested  in.  However,  this  approach  runs  counter  to  realistic  operational  team 
performance,  and  to  the  aims  of  the  overall  A2C2  project. 

The  planning  process  would  be  a  very  likely  time  within  the  span  of  an  operation 
for  adaptation  of  organizational  architectures  to  take  place,  because  of  the  relative  leisure, 
thoughtfulness,  and  potential  for  putting  minds  together  to  solve  a  problem  in  the 
planning  environment,  compared  to  the  more  hectic  “crisis  management”  atmosphere  that 
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prevails  once  the  execution  phase  has  begun.  Additionally,  commanders  would  probably 
be  more  willing  to  adapt  the  structure  of  their  organization  during  the  planning  phase  than 
they  would  during  the  execution  phase.  Alternatively,  a  planning  phase  (for  the  next 
portion  of  the  operation)  and  the  execution  phase  (for  the  current  portion  of  the  operation) 
could  happen  concurrently,  or  need  to  happen  concurrently,  which  in  and  of  itself  could 
drive  adaptation,  in  order  to  facilitate  conduct  of  both  phases  simultaneously.  For  these 
reasons,  not  only  should  a  planning  phase  be  included  in  any  future  experiments  and 
scenario  (or  concurrent  planning  and  execution  phases),  but  that  phase  should  be  a  major 
focus  of  study. 

C.  SUMMARY  OF  THESIS 

This  thesis  was  conducted  as  a  part  of  the  Adaptive  Architectures  for  Command 
and  Control  (A2C2)  project,  which  seeks  to  explore  adaptation  in  command  and  control 
structures.  The  project’s  first  experiment  involves  studying  interaction  between  task 
structure  and  organization  structure.  This  thesis  described  a  process  for  developing 
military  operational  scenarios  within  a  task  structure  context.  First,  I  conducted  a 
literature  review,  defined  the  dimensions  of  task  structure  applicable  to  this  project, 
developed  a  grading  scale  for  each  dimension,  gave  examples  of  the  dimensions  and 
graded  each  example,  and  described  how  changes  in  one  dimension  might  affect  other 
dimensions.  Then  a  method  for  developing  scenarios  in  accordance  with  a  predetermined 
structure  and  visualization  of  tasks  was  described,  including  a  task  structure  diagram  and 
a  description  of  a  task  design  process  using  the  diagram  and  the  dimensions  previously 
delineated.  I  then  applied  the  task  design  process  by  developing  two  scenarios  for  the  first 
A2C2  experiment  that  differed  across  one  of  the  dimensions  of  task  structure, 
coordination  requirements.  Finally,  I  gave  a  description  of  the  experiment,  including 
discussion  of  operationalization  of  the  scenarios  and  organization  structures,  and  lessons 
learned  from  the  experiment  and  application  of  the  task  design  process  with  regard  to 
scenario  design. 
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